Joel Hooks' SignalCommandMap vs Regular Signals

Dave's Avatar

Dave

19 Jul, 2011 07:47 AM

Hello.

I appreciate the type safety provided by signals and am looking forward to replacing my events but in researching how to implement signals I came across two different techniques. The first was demonstrated nicely in John Lindquist's tutorial found here:

http://johnlindquist.com/2010/01/21/as3-signals-tutorial/

His signal was called Superhero, and had methods like .punch(String) and .kick(String). This is different to Joel's signalCommandMap explained here:

http://joelhooks.com/2010/02/14/robotlegs-as3-signals-and-the-signa...

In this scenario Joel mapped signals to commands in his new SignalContext class. It also seems that this method can be extended with Stray's signalMediator found here:

https://github.com/Stray/robotlegs-utilities-SignalMediator

Joel justified his differing approach by saying:

'Command signals are named a bit differently than standard reaction Signals. A Signal that is triggering a command is "requesting action" or specifying an action that needs to occur. Standard signals are typically past tense, or informative, describing an action that has occurred. By using this standard it is much easier to differentiate quickly what each Signal's purpose is. This can help with overall clarity within your application.'

This is a fair argument but it is brief and for the life of me I can't find any counter points raised by somebody else (or any discussion at all). Although I was able to find clear reasons to code in Robotlegs over other flash frameworks and likewise in choosing signals over events, I can't clearly decide in favour of signal methods or signal-command mapping. Does anyone have any advice or experiences to share on the most common way to implement signals into your app?

All I have so far is many methods Vs. many classes.

Cheers

PS: out of curiousity, does anybody know if robotlegs 2 will do anything special with signals?

  1. Support Staff 2 Posted by Stray on 21 Jul, 2011 03:10 PM

    Stray's Avatar

    Sorry for the delay - your message was stuck in spam (oops).

    I'd say forget methods vs classes and think in terms of responsibilities and ownership.

    If a timerModel dispatches a tick signal, this signal is probably a property of that timerModel. It belongs with the timer.

    On the other hand a 'quit' signal doesn't really 'belong' to any one class in most applications (unless you have a giant state machine for this but ignore that possibility for now). So it sits better for me as a stand-alone.

    I think John's 'signal' is still a model - it just uses signals.

    I like to mix it up and I generally use all 3 approaches: injected strong-typed signals, signal-properties of objects and events. They each have pros and cons and I like to pick the most appropriate one for each task.

    Signals are probably too new for there to be a real gospel on how best to use them - even Robert is switching back and forth on whether he likes signal buses and so on or not.

    As for RL2 - we plan to build the feature set with events first and then provide signals driven and events+signals driven alternatives. Robotlegs 2 is more of a "This - plus - this - plus - this" approach (ie you specify which maps you want to include) so it'll be much easier to implement signal and mixed alternatives to the core maps.

    Stray

  2. 3 Posted by Timur on 21 Jul, 2011 06:57 PM

    Timur's Avatar

    @Dave,

    Since I'm studying the same aspects of RL & Signals-Event integration, my take on it is that John's excellent tutorial demonstrates the usage of Signals outside of any framework (Robotlegs) per se, whereas Joel's signalCommandMap tutorial demonstrates how to map signals to RL commands, and Stray's SignalMediator extends RL's Mediator and allows one to use SignalMap to map signals to handlers alongside an eventMap that does the same for events. That's the way I see it at least.

    @Stray,

    I like to mix it up and I generally use all 3 approaches: injected strong-typed signals, signal-properties of objects and events. They each have pros and cons and I like to pick the most appropriate one for each task.

    Could you please give us an example of how you'd use each of the three. I think a concrete example would help cement these concepts for many, not necessarily as a real gospel, as you say, but rather, as a rationalized approach.

    Thanks again,

    Tim

  3. 4 Posted by Stray on 21 Jul, 2011 07:25 PM

    Stray's Avatar

    Hi Tim,

    ok - so:

    I use injected signals to create a one-to-one channel between a mediator and a command, for example if there are multiple instances of the same view on stage, and the user has clicked 'next' in one of them, so that the next set of data comes specifically to this view.

    These signals are not a property of any object - they stand alone.

    I use property-signals from my views to my mediators if the view is complex. So - a log in panel might expose signals for submit, quit, forgotPassword.

    I use events for pretty much everything else (though I might well use signals more and more in future).

    Does that help?

    Stray

  4. 5 Posted by Timur on 21 Jul, 2011 09:57 PM

    Timur's Avatar

    Hi Stray,

    So in the first example, you inject a signal into your command, instead of mapping the signal in your mediator to your command (the one to one channel)? I'm not sure if that's it.

    These signals are not a property of any object - they stand alone.

    Where do they get instantiated, then?

    I use property-signals from my views to my mediators if the view is complex. So - a log in panel might expose signals for submit, quit, forgotPassword.

    OK. I do something along those lines (I think):

    <s:Button id="save_btn" click="saveButtonClickedSignal.dispatch()" />
    

    Then in the view's mediator I can listen for the saveButtonClickedSignal.

    I use events for pretty much everything else (though I might well use signals more and more in future).

    OK, but if Signals are more performant than Events, require less code to create than events, and bubbling notwithstanding, then the only advantage I have found discussed so far is the fact that one Event could have multiple String Constants doing the job of several signals (if I understood it correctly, that is). I really like the visual compactness of Signals. Once you start using them, they could become second nature rather quickly.

    Thanks for you illustrations and explanations, Stray!

    Tim

  5. 6 Posted by Stray on 22 Jul, 2011 08:06 AM

    Stray's Avatar

    Hi Tim,

    They are "Signaltons" - ie Singleton Signals - and the SignalCommandMap takes care of the mapping on the injector. They will be instantiated the first time something requires them to be injected.

    There are some pragmatic reasons why I've continue to use Events (as well as Signals):

    1) The Signals library is still in beta and until it hits 1.0 the API is subject to change, as well as the composition of interfaces.

    2) I'm integrating parts of code that are events based (utilities etc)

    3) For some things - for example logging - I think events are a better fit with my mental model of what's going on.

    4) My app is modular, and my modules don't share injections or app domains. It's much easier to relay events between modules than it is to re-wire signals - you end up having to create signal buses so that you can pass a smaller number of objects as your objects have to 'belong' somewhere. I call these 'channels'. It works and has great use cases but in my mind it defeats much of what is good about signals and in that form it doesn't really give you any advantage over events (milliseconds are irrelevant in my app).

    5) Adding listeners to signals is order-of-operations dependent. Event listeners are much more neutral about order-of-ops. Which again makes it easier to work with Events in a situation where you have multiple modules being loaded in various combinations over time.

    6) Robotlegs gives you some degree of type safety for events - almost on a par with Signals except that you can still dispatch silly things, and you don't get a useful error message like you do with signals. I use TDD so I am pretty sure my code isn't dispatching silly things.

    However - don't take that to mean that I don't love Signals. I love both - they are quite different in what they offer though.

    I even use the two in combination - I sometimes create RequestEvents that contain a response signal for the command to reply on.

    I hope that make sense :) I think it's odd that so many people have gone straight for the "I'm a signals person" or "I'm an events person" dichotomy - to me it feels like saying "I'm a keyboard person" or "I'm a mouse person". You might have a preference for one or the other, but the best approach is to combine the two!

    Stray

  6. 7 Posted by Joel on 23 Jul, 2011 04:42 AM

    Joel's Avatar

    https://m.google.com/app/plus/mp/451/#~loop:backv=notifications&amp...

    This is an interesting discussion about where I'm at with the SCM

  7. 8 Posted by Dave on 24 Jul, 2011 05:19 AM

    Dave's Avatar

    Hi all, I'm sorry for responding so late after the fact.

    @Stray, thanks very much for phrasing it in terms of responsibilities - that clears things up very much. Also Timur, after looking at it again it does seem to be the way you said - John's tutorial was not as a part of Robotlegs, while the SignalCommands and SignalContext's obviously are.

    I think I'm going to use all three methods, signals, signalCommands and events, similar to Stray. The key to maintainable code is consistency, so I'll use responsibilities to decide which kind of signals to be using in my app, and leave things as events at the fringe of the app, where I communicate using flash events for services and the like.

    Or at least that's where I was before reading Joel's link. I've other things to do so I can push signals back a bit while I reconsider using them. Since it's a relatively big project the "cognitive overhead" described by Joel could become a real issue.

    Thank you everyone for the advice. I kind of assumed signals were the way to go simply because I'm wary of the string matching used by events but since you can specify the event class in the Context that's not as huge a problem as it could be.

  8. 9 Posted by Timur on 26 Jul, 2011 09:20 PM

    Timur's Avatar

    Hi Dave,

    Not that I'd want you to switch your IDE, but John Lindquist has created a very useful plugin for Intellij IDEA that, I think will help reduce some of the mental burden associated with following the breadcrumb trail of mediators/views, commandMaps/events, and more. Like Stray said, it really is a case of using code-gen as much as possible and have tools that help with the wiring.

    Tim

  9. Ondina D.F. closed this discussion on 01 Nov, 2011 03:33 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac