Adds the ReplaySignal type. #50
Conversation
Adds an "addConditionally" method to ISignal.ISignal#addConditionally ad
ds a "conditional" listener to the signal. If the listener returns a tru
thy value (true, > 0, not null) when it's invoked, the listener is remov
ed. If it returns a falsey value (false, 0, null, void), the listener is
n't removed.
For example, this is useful for a "fire-hose" Signal, whic
h can dispatch multiple types.
> const firehose:ISignal = service.subscr
ibeToSharedEventStream();
> const typeAHandler:Function = function(obj:*
):void{
> if(!(obj is TypeA)) return;
> //else do something...
> fire
hose.remove(typeAHandler);
> }
> signal.add(typeAHandler);
> service.su
bscribeToSharedEventStream()
> .addConditionally(function(obj:*):Boolean
{
> if(!(obj is TypeA)) return false;
> //else do whatever and remove
the listener
> return true;
> });
ReplaySignal is inspired by Rx.NET's IObservable.Replay() extension meth od. ReplaySignal can replay the entire dispatch history of the signal to [new] observers, no matter when they're added. For more information, se e Lee Campbell's writeup of Rx's Replay() method here: http://leecampbel l.blogspot.com/2010/08/rx-part-7-hot-and-cold-observables.html
|
Does this really need to affect the ISignal interface and the Signal class? Could this not be added extras rather than get everything at once. Therefore keeping ISignal and Signal simple and easy to use? |
|
ReplaySignal is orthogonal to conditional listeners, but since I've advanced my branch, I support it on Replay. Conditional listeners are a nice idea. Both commits make it easier to use signals as promises (or futures). |
|
Agreed, I just don't think everyone will use them (I would though) which is why I'm wondering if there was a way to include them and not have to put it in ISignal? |
|
I see the potential to roll the addConditionally() functionality into the add() method (more correctly, into SignalBinding), but it feels like ambiguous API. It most likely wouldn't break backwards compatibility. I'd bet lots of money the return type of most people's listeners is void, but there's always the edge case where a developer from JavaScript fooled himself into thinking he always needs to return TRUE but doesn't know why. I use signals to write APIs based on promises, fluent interfaces, and a declarative asynchronous style. These pull requests are just my small contribution back to the library to help encourage developers towards this style. :) |
|
Here's a small example of ReplaySignal in action: https://gist.github.com/1107886 |
|
nice looks good, still be good to hear what Robert thinks of the additions to ISignal and the like? On 26 Jul 2011, at 21:19, guyinthechair wrote:
|
ReplaySignal is capable of replaying its dispatch history to its observers. It can also automatically replay its history to each new observer when it's added. ReplaySignal is inspired by Rx.NET's IObservable.Replay() extension method. For more info, see Lee Campbell's writeup here: http://leecampbell.blogspot.com/2010/08/rx-part-7-hot-and-cold-observables.html