Reactive: Proposal: Ship SerialDisposable<T>(); and CompositeDisposable<T>(); and others

[ghuntley]

See https://github.com/kentcb/Genesis.GenericSerialDisposable I'm sure @kentcb would be keen to retire his implementation to get this included by default.

[kentcb]

Well.....no, not really. Here's the thing: SerialDisposable<T> depends only on Rx, and I often use it in contexts that do _not_ require RxUI. It would actually make things harder/messier if this was bundled in RxUI.

[ghuntley]

@kentcb this is the System.Reactive repo, not ReactiveUI repo. Apologies for the context shift as you were also reviewing some RxUI PRS at the same time. This proposal is to lift your implementation and ship it, in, the official rxnet package.

[kentcb]

lol, oops. Carry on, soldier.

In that case, not only could it be lifted, but it could be made more efficient (avoid casting and such). I'd be all for this and would be happy to PR it if there's a general consensus that this is A Good Thing.

[JohanLarsson]

SerialDisposable<T> and CompositeDisposable<T> would make sense in Systemor System.Core imo. They are general purpose and probably copy-paste ~reimplemented in many apps & libs.

[mattpodwysocki]

I'm not sure what this would buy us other than API bloat in our own library since I'm not sure it would be useful in Rx .NET core. If on the other hand, we had say System.Reactive.Disposables as its own package, then perhaps that would make sense.

[RolandPheasant]

@mattpodwysocki having another package gets my thumbs up as they are useful outside of Rx

[RxDave]

+1 for a separate library, but should it be System.Disposables without "Reactive" in the title? There's nothing actually reactive about any of the disposable types in Rx.

[mattpodwysocki]

@RxDave we weren't allowed to touch the System namespace in .NET outside of System.Reactive so that's why I was proposing keeping it there.

[clairernovotny]

Perhaps the idea of a Disposables library belongs directly in the CoreFx repo? It can start off as a spec/discussion and see if it fits in one of the existing libraries or if it should be its own thing like System.Disposables?

[mattpodwysocki]

@onovotny I wouldn't be opposed. Feel free to start the discussion.

[colombod]

same would apply to the IScheduler interface as well, should be a core interface that I can use. to bring in rx only for that interface is not so convenient

[shiftkey]

@colombod can you open a different issue for IScheduler with details about the non-Rx use case you would like to see supported?

[bartdesmet]

One of the original goals of System.Reactive.Interfaces and System.Reactive.Core was to reduce the amount of stuff one needs to include if one is interested in e.g. the disposable algebra or the scheduler functionality. In particular, it cuts out large assemblies such as System.Reactive.Linq and System.Reactive.Providers. In fact, at some point in the past, the schedulers were in their own concurrency assembly which was also used by System.Interactive.

If anything, it'd make sense to split these off into an even more fine-grained set of assemblies again. Such assemblies can become very concrete minimal units of functionality that can be used as proposals for inclusion into corefx, potentially with a stop over at corefxlabs. FWIW, I've never been a fan of trying to smash assemblies together for a perceived light-weight nature based on e.g. seeing the number of assembly references in a Visual Studio project. Finer grained is the better side to err on.

[colombod]

I just think that as IDisposable, Observer and IObservable are part of .net BCL same should be for the IScheduler. That would make contract assemblies untied to RX, a lot of time need to bring a dependency on rx overtime i am exposing the IScheduler through my interfaces, that coupling should be only at implementation.

[akarnokd]

Looks like the discussion of the inclusion has stalled here and in the corefx proposal too. For one thing, they are pretty much Rx-concurrency specific. Ix.Async doesn't use them nor can I recall any other forms of async approaches working with the type. The concept itself is simple enough to be included/adapted to other types.

However, 4.x inlined most usages of the types and uses direct field updating instead of allocating a holder.

If the remaining holders get eventually into the corefx, we can revisit this issue similarly to the Ix.Async work.