modify ReplaySubject (with specified capacity) to comply with original reactive extensions behaviour #753
Conversation
…aviour the capacity of ReplaySubject specifies maximum element count of the replay buffer code: https://rx.codeplex.com/SourceControl/latest#Rx.NET/Source/System.Reactive.Linq/Reactive/Subjects/ReplaySubject.cs test: https://rx.codeplex.com/SourceControl/latest#Rx.NET/Source/Tests.System.Reactive/Tests/Linq/Subjects/ReplaySubjectTest.cs
|
RxJava-pull-requests #668 FAILURE |
…y-subject-with-capacity Conflicts: rxjava-core/src/main/java/rx/subjects/ReplaySubject.java
|
RxJava-pull-requests #669 FAILURE |
|
RxJava-pull-requests #670 SUCCESS |
|
Hi, not really necessary as Edit, btw, the create(initialCapacity) isn't meant for bounded buffering but to set the capacity of the internal buffer to avoid constant reallocation if it needs to grow. |
|
I agree the initialCapacity isn't meant for bounded buffering. This is where the confusion comes from. I am writing the same application on both iOS (ReactiveCocoa) and Android(RxJava). The different behaviours of ReplaySubject with capacity is confusing. ReplaySubject on ReactiveCocoa I think it is good to keep the behaviour consistent across different platforms, following the original .Net reactive extensions design. :) |
|
ReplaySubject should behave the same as Rx.Net. Any different behavior is a mistake. |
Are you referring to something like this? Subjects.createAsync();
Subjects.createBehavior();
Subjects.createPublish();
Subjects.createReplay();
Subjects.createReplayBuffered(size);
Subjects.createReplayBuffered(size, time);However, in this case the following seems clearer: AsyncSubject.create();
BehaviorSubject.create();
PublishSubject.create();
ReplaySubject.create();
ReplaySubject.createBuffered(size);
ReplaySubject.createBuffered(size, time);In general I prefer the latter. On Are there generic things that belong on a |
|
Thank you @wangsha for getting involved. I believe we have all of the ConnectableObservable<T> replay()
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, int bufferSize)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, int bufferSize, long time, java.util.concurrent.TimeUnit unit)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, int bufferSize, long time, java.util.concurrent.TimeUnit unit, Scheduler scheduler)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, int bufferSize, Scheduler scheduler)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, long time, java.util.concurrent.TimeUnit unit)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, long time, java.util.concurrent.TimeUnit unit, Scheduler scheduler)
<R> Observable<R> replay(Func1<? super Observable<T>,? extends Observable<R>> selector, Scheduler scheduler)
ConnectableObservable<T> replay(int bufferSize)
ConnectableObservable<T> replay(int bufferSize, long time, java.util.concurrent.TimeUnit unit)
ConnectableObservable<T> replay(int bufferSize, long time, java.util.concurrent.TimeUnit unit, Scheduler scheduler)
ConnectableObservable<T> replay(int bufferSize, Scheduler scheduler)
ConnectableObservable<T> replay(long time, java.util.concurrent.TimeUnit unit)
ConnectableObservable<T> replay(long time, java.util.concurrent.TimeUnit unit, Scheduler scheduler)
ConnectableObservable<T> replay(Scheduler scheduler) Unfortunately though, I don't think it's all been implemented using We need to fix this and make ReplaySubject<T>() Creates a replayable subject.
ReplaySubject<T>(Integer) Initializes a new instance of the ReplaySubject<T> class with the specified buffer size.
ReplaySubject<T>(TimeSpan) Initializes a new instance of the ReplaySubject<T> class with the specified window.
ReplaySubject<T>(Scheduler) Initializes a new instance of the ReplaySubject<T> class with the specified scheduler.
ReplaySubject<T>(Integer, Scheduler) Initializes a new instance of the ReplaySubject<T> class with the specified buffer size and scheduler.
ReplaySubject<T>(Integer, TimeSpan) Initializes a new instance of the ReplaySubject<T> class with the specified buffer size and window.
ReplaySubject<T>(TimeSpan, Scheduler) Initializes a new instance of the ReplaySubject<T> class with the specified window and scheduler.
ReplaySubject<T>(Integer, TimeSpan, Scheduler) Initializes a new instance of the ReplaySubject<T> class with the specified buffer size, window and scheduler. |
|
@akarnokd Since you have implemented most of the This should of course not lose the benefits we gained from the 0.16.0 work such as in #651 |
|
A simple thing is to expose OperationReplay.replayBuffered in ReplaySubject. Rewriting CustomReplaySubject to use similar state machine is more complicated and I can't do it this week. |
|
@akarnokd , @benjchristensen cool. Thanks for looking into this issue. Looking forward to the update. |
…y-subject-with-capacity
|
RxJava-pull-requests #683 SUCCESS |
|
RxJava-pull-requests #709 FAILURE |
…ubject-with-capacity Conflicts: rxjava-core/src/main/java/rx/subjects/ReplaySubject.java rxjava-core/src/test/java/rx/subjects/ReplaySubjectTest.java
|
RxJava-pull-requests #710 FAILURE |
|
Keeping this open for now as I will merge this onto my branch when I work on |
|
Closing out. This is referenced from #865 |
modify ReplaySubject (with specified capacity) to comply with original reactive extensions behaviour
the capacity of ReplaySubject specifies maximum element count of the replay buffer
code:
https://rx.codeplex.com/SourceControl/latest#Rx.NET/Source/System.Reactive.Linq/Reactive/Subjects/ReplaySubject.cs
test:
https://rx.codeplex.com/SourceControl/latest#Rx.NET/Source/Tests.System.Reactive/Tests/Linq/Subjects/ReplaySubjectTest.cs