You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Disposable is used in two key areas in the public API:
Resource collection and cleanup. Signal generator, SignalProducer start side effect.
Work cancellation. SignalProducer work cancellation, Signal observer detaching, Scheduler work cancellation.
While there is likely no sensible alternative for work cancellation tokens, the newly introduced Lifetime seems a nice contender to the use of Disposable for resource management in Signal and SignalProducer.
For example, we may have instead:
letproducer=SignalProducer{ observer, lifetime in// Attach a resource to the lifetime of the produced `Signal`.
lifetime += signal.observe(observer)}letsignal=Signal{ observer, lifetime in// Attach a resource to the lifetime of the produced `Signal`.
lifetime += upstream.observe(observer)}
The key change here is that the "garbage collector" passed to the SignalProducer start handler are no longer disposable. CompositeDisposable as the public interface allows it to be disposed in the start handler, while it is supposed to be disposed only upon external interruption.
Edit: API changes
This would break sources that somehow relies on this though. I am not sure about the impact, but it feels like a fringe case.
The SignalProducer change would be breaking due to conflicting signature with existing initializer. Even if we replicate the CompositeDisposable API on Lifetime, it breaks whenever the second argument type is not inferred but explicitly specified.
The Signal change, however, is purely addictive to ReactiveSwift 1.0. The Signal change would be breaking due to closure return type not being able to be inferred from multi-line body.
As an extension, we may also introduce a new variant of observe, which associates an observation with the given Lifetime (or trigger signal).
The main advantage over take(until:) would be avoiding an extra Signal just to forward the events when used at the tail of a signal composition, at a cost of expanding the reach of the observation APIs.
The text was updated successfully, but these errors were encountered:
@mdiep The cleanup for producers does not differentiate between cancellation and termination. The collected resources are disposed of when the signal is terminated regardless how it terminates.
So it is actually a synonym of observing the termination of a Signal, just without affecting the Signal's lifetime like how a normal observer does.
Originally: ReactiveCocoa/ReactiveCocoa#2044
Currently,
Disposable
is used in two key areas in the public API:Resource collection and cleanup.
Signal
generator,SignalProducer
start side effect.Work cancellation.
SignalProducer
work cancellation,Signal
observer detaching,Scheduler
work cancellation.While there is likely no sensible alternative for work cancellation tokens, the newly introduced
Lifetime
seems a nice contender to the use ofDisposable
for resource management inSignal
andSignalProducer
.For example, we may have instead:
The key change here is that the "garbage collector" passed to the
SignalProducer
start handler are no longer disposable.CompositeDisposable
as the public interface allows it to be disposed in the start handler, while it is supposed to be disposed only upon external interruption.Edit: API changes
This would break sources that somehow relies on this though. I am not sure about the impact, but it feels like a fringe case.
The
SignalProducer
change would be breaking due to conflicting signature with existing initializer. Even if we replicate the CompositeDisposable API onLifetime
, it breaks whenever the second argument type is not inferred but explicitly specified.TheTheSignal
change, however, is purely addictive to ReactiveSwift 1.0.Signal
change would be breaking due to closure return type not being able to be inferred from multi-line body.As an extension, we may also introduce a new variant of
observe
, which associates an observation with the givenLifetime
(or trigger signal).The main advantage over
take(until:)
would be avoiding an extraSignal
just to forward the events when used at the tail of a signal composition, at a cost of expanding the reach of the observation APIs.The text was updated successfully, but these errors were encountered: