Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Subscription Utilities and Default Implementations #173
Provide a createSubscription() utility that returns a Subscription implementation that is thread-safe that provides an isUnsubscribed() getter to be used by most Observables via Observable.create() since most of the time they just need a thread-safe volatile/atomic boolean to check in a loop.
Also, where should it go along with these:
public static Subscription createSubscription(final Action0 unsubscribe) public static Subscription createSubscription(final Object unsubscribe) public static Subscription noOpSubscription()
Should this be on Observable or should a new Subscriptions utility class exist?
The type of things to model in Rx are here: http://msdn.microsoft.com/en-us/library/system.reactive.disposables(v=vs.103).aspx
Disposable == Subscription in RxJava.
The 'Disposable' name means something special in C# similar to AutoCloseable (http://docs.oracle.com/javase/7/docs/api/java/lang/AutoCloseable.html) in Java7 (which is why Subscription doesn't implement AutoCloseable yet since we are sticking to Java6).
We want an
Subscription is currently an interface (which I like in this case since it can be a FunctionalInterface in Java8 and implemented with lambdas) but it means we can't exactly model the Subscription.create() method signature of Rx.Net.
I'm torn ... as Subscription.create() would be a very nice method signature.
We could have `rx.subscriptions.Subscriptions' as the utility method but it's slightly contrived.
rx.subscriptions.Subscriptions.create(final Action0 unsubscribe) rx.subscriptions.Subscriptions.create(final Object unsubscribe) rx.subscriptions.Subscriptions.empty()
Then we'd have a class like `rx.subscriptions.BooleanSubscription' which is what would provide the functionality most Observables want.
Anyone have thoughts on what decisions to make with this API?
This was never tackled internally at Netflix as we just had custom Subscription objects that implement the interface - but that's not appropriate for a standalone library, particularly when trying to comply with the Rx.Net design and API.
I like the idea of creating Subscriptions class and moving it alongside with a Subscription interface to a separate package.
It seems like .NET naming convention dictates that interfaces should start with
Besides that I see there are several wrappers in a
This was referenced
Mar 11, 2013
Done ... interested in people's review however. Will be part of 0.6.0 as it involves some small breaking changes in the pursuit of trying to match Rx.Net (such as this https://rx.codeplex.com/SourceControl/changeset/view/6bf8a7952bdd#Rx/NET/Source/System.Reactive.Core/Reactive/Disposables/Disposable.cs)