You mentioned in the previous 'Subscribe' video that 'unSubscribe() methods in many event frameworks are not compositional' ...
Why??? What makes dispose() more compositional than unSubscribe()?
Could you explain?
My understanding is that the Dispose() method is more compositional than unsubscribe because if your code doesn't call unsubscribe, the .NET Framework Garbage collector will do it for you (eventually). This can help alleviate issues that Event handlers suffer
from, where if you do a += handler and not a -= handler it won't leak memory. Also Dispose() is called automatically when the IObservable completes or errors.
Thanks for the explanation!
Regarding the contract, I'm wondering about the case where an IObservable<> represents a finite source of (uncached) external "events".
Just imagine a postal service that exposes (for each handled letter or parcel) a member of type IObservable<DeliveryStatus>, where DeliveryStatus represents the location of the letter/parcel; whenever the barcode of the parcel is scanned, the location is
notified to the subscribed observers; the IObservable<> is done (invocation of observers' OnDone() method) when the recipient receives the letter/parcel.
My idea is that when a client application receives/gets this IObservable<> and subscribes a matching IObserver<>, the letter may already have reached its destination since seconds/minutes/days (my country has a very efficient postal service).
Would each of the following be considered as an acceptable behavior?
1- The observer never gets any of its members invoked.
2- The observer's OnDone() is invoked on subscription.
3- The observer's OnNext() is invoked with the final location, then OnDone() is invoked; both invocations being done on subscription.
4- The observer's OnException() is invoked on subscription ("Parcel already arrived, dummy !")
Is one of these behaviors preferable?
Moreover, as a designer of such
a "postal service notification framework", do I have a mean to force implementors to adopt one of the
above (1-4)? (I guess
Thanks for your insight.
Rx allows all of the above options. It really depends on what you're looking for. option 1 would be the default behavior. if you had used a AsyncSubject or ReplaySubject, you could get option 3. option 1 and 4 you'd have to implement manually using Observable.Create.
Hope this helps,
First of all, thanks for your answer: I'm now sure the options I listed are valid implementations from Rx point of view.
And as the behavior of the IObservable depends on the choices made for the concrete type implementation, this also answers my second question.
So yes, your answer helped.
Thanks again (and please don't stop your "Rx in Depth" post series !)