My husband, @SteveHoward999, says I often assume what is obvious to me is obvious to everyone, so let me go back and spell out in so many words what I believed at the outset should have been obvious, just in case it wasn’t.

Clint, in his original post, says: “others like myself, like to strongly type events with value objects wherever I can (resulting in many custom event classes per project).” I presumed, rightly or wrongly, that this means that he found value in these strongly typed Events–specifically, in their Value Objects. This seams to me to be a reasonable reading of the sentence.

From there I said that this strong typing is lost when you use Signals. Again, it is very abundantly obvious to me, and several people have confirmed, that Signals CANNOT check that the arguments on listening functions are of the correct type, and certainly not at compile time. This is simply due to the way that As3 handles function references.

By contrast, you CAN’T use dispatchEvent() to dispatch, say, a DisplayObject. So, at the very least, you know that you’re getting an Event. I suppose that some developers have trouble constantly dispatching or listening for the wrong Event Class but, in practice, I have never encountered this problem–and I have seen a lot of truly atrocious code.

The simple signatures for both dispatching and receiving events make _that_ part of the process pretty idiot proof. And the compiler will alert you if you try to add an event listener that doesn’t have at least one argument–something that you’ll only get warning of at runtime with Signals.

Several people have talked about the type _property_ of an Event Object as somehow being involved in its type safety. This property is, in fact, a strongly typed Object (a String), but it doesn’t matter whether you are using a strongly typed event, a regular Flash Event, or a DynamicEvent with a data property, this property always has exactly the same type safety. You can help make sure the same String is used throughout the application by using Constants, but whether those constants are used as part of the Event Class definition or not (or whether you don’t even use constants) has zero bearing on the type safety or lack therof of the property.

So, it was very clear to me that this was _not_ what I was saying about the type safety you throw away by not using Events. I was actually pretty surprised to be asked to defend a position I didn’t take on this.

I will say this: I think that the “type” property has a very clear semantic meaning, which is “this is the specific way I want this (Class of) Event dealt with.” The Flash Player has traditionally dealt with this by routing all Events with the same type property to the same handler, without regard for the actual Class of the event. However, the way that Robotlegs handles this, by looking at both “type” and type, proves that the semantics of the default Event object are quite workable. If the FP implementation is a bit flawed, it still works extremely well.

Now let’s look at the suggestion of using Signals to send an Event directly to a function. The Signal itself coopts and repeats the meaning of the Event’s type property, and this property (the only mandatory Event property) could well become meaningless. While this might have value in retrofitting Event-based code to use Signals, in new code this has a bad smell IMO.

I’m going to move on to talking about my philosophy toward loose coupling, which is to use the absolutely least prescriptive Class Type needed to accomplish the job. If I have, say, a LoginView that has a SimpleButton that dispatches a bubbling LoginEvent, I can listen for that event on a LoginView instance without knowing anything about it other than it is a DisplayObject. If I needed to take it that far, I could type it as IEventDispatcher.

However, to listen for a Signal to be dispatched, I _have_ to know about a Signal instance, so if we have a bubbling child Signal, at the point we’re listening to it the parent needs to implement IBubbleEventHandler and have a matching Signal itself. This means that (in normal usage), we need to know something fairly custom about the Class involved here.

In order to dispatch our LoginEvent from our SimpleButton, we don’t have to do anything but call the dispatchEvent function that it already has. And–and–LoginView doesn’t need to have any knowledge that something has happened.

To dispatch the bubbling Signal, you need to add the Signal and call its dispatch() method in the child view, then catch it and redispatch it in the parent.

From a loose coupling point of view, this all doesn’t sound like better architecture. It’s not that you can’t make it work, but I don’t find the thing you see as so advantageous–the necessity for direct knowledge of a property on the object you want to listen to (and for parents to be so concerned about what is going on inside them)–to be a good thing in a general sense.

Anyway, like I said, I felt I owed it to those following the discussion to come back and clarify the points I may not have been very clear on before. If I have failed this time, I apologise. This was my best shot, and I don’t see much point in continuing to discuss if it didn’t work.

“As Rob says, the way functions are treated in AS creates some fundamental weaknesses whenever you use functional techniques, and these are at the core of the problems I have with As3Signals.”

How exactly do functions create problems for AS3 Signals but NOT for Events?

Listeners for Events and Signals are basically the same. The main difference is that Signals doesn’t force a certain signature (event:Event) on you. If listener references that lose type safety are bad for Signals, they’re also bad for Events.

Are you able to explain your core problems with Signals any further? So far I haven’t seen anything from you re: AS functions that applies only to Signals.

“It looks like somewhere in there we lost track of the fact that I was originally talking about code hinting help from the IDE”

Ok, help me not to lose track. Do you have other examples besides FontStylingEvent? Examples where Events allow better IDE code hinting than Signals?

“If I receive an object of type FontStylingEvent, code hinting will, indeed, tell me it has a fontStyling property.”

Is that really all you’re talking about re: code hinting? In this case, Events don’t have an advantage over Signals, which can send FontStylingEvent or anything else.

I’d like to repeat my earlier question you haven’t answered:

How exactly do custom Events give you more type safety than Signals?

You said “[With Signals] you’ve also given up what those custom typed events gave you–type safety”. I gave several examples of how Signals improve type safety over Events. Do none of these matter to you? Is there still some pocket of functionality where you think Events have more type safety than Signals?

Type safety was the first concern you brought up in your critique of Signals. At this point, I’d consider that debunked.

Yes. Correct. I interpret this as a benefit of Signals – a breaking change in terms of app behaviour is also a breaking change to the compiler. No silent just-didnt-do-what-it-was-supposed-to bugs.

“I tend not to write custom events for events that do not have a payload (which are few), preferring instead to have a Class that simply defines the constants.”

You mean you actually prefer strings to strong typing?

“First off, thanks for the discussion. I’ll be clear that my objective isn’t to convince everyone to use AS3 Signals all the time.”

You too . I actually have a very strong interest in Signals, especially if NativeSignal can do better filtering on native Events (not call every listener and then make them filter on event properties). I plan to get there eventually, but I keep getting sidetracked on things that won’t take me 2 solid days to do.

“I wouldn’t say “no way (to know the types of arguments that will be dispatched).” If that were the case, developers would get frustrated and stop using Signals. Here are three ways people can, and do, have confidence in their listener signatures:

- documentation
- source code
- the code works without throwing a Type Coercion failure”

It looks like somewhere in there we lost track of the fact that I was originally talking about code hinting help from the IDE–any time you have to go look something else or, worse, run the code to find out I’ve made a mistake is going to slow me down. Maybe I would fare better if I weren’t using Flash Builder on a Mac these days, but I don’t find that it makes efficient use of the screen real estate I have easy.

“Events only support code hinting when [Event] metadata is used AND kept in sync with the relevant ActionScript AND a specific convention with Event constants is followed. If any of these 3 three stringy links is broken, the chain fails.”

I think we’re talking about two different things here. If I receive an object of type FontStylingEvent, code hinting will, indeed, tell me it has a fontStyling property.

I usually don’t care about the kind of code hinting you’re talking about, because my events will either be sytem level events (dispatched against the central event bus by a Mediator, Command, or Presentation Model), or they’ll be so extremely local that there’s no issue taking a more direct route (looking at the code) to seeing what events are being dispatched.

When events are dispatched against the central event bus, they nearly always have a payload and thus will have a type constant defined by the custom event. I tend not to write custom events for events that do not have a payload (which are few), preferring instead to have a Class that simply defines the constants.

I agree with everyone in this discussion that Signals is a great idea and that its weaknesses are primarily due to failures in As3. However, those weaknesses do exist, and right now I don’t find the argument for Signals compelling enough to incorporate it, though I have in a previous project with different goals and limitations.

“There is a clear conceptual difference between ‘not dispatching’, because the implementation has blocked it, and ‘never relevant’.”

The thing is, that if suddenly you decide that it’s not relevant anymore, you can’t remove the Signal without breaking whatever is listening for it–because it requres that you directly reference the Signal itself. I know that things like the SignalCommandMap somewhat alleviate this, but I’m talking about in normal use.

If you remove code that dispatches an event, all the code that was intended to trigger when it fires is still relevant and could be called upon if you change your program again.

“As Rob says, it means when I add a listener to a custom object I often have to start referring to the AS3 reference to check exactly what event is dispatched when by this object.”

…and you have to look at the Signal to see what data types will appear in the arguments list. I think that’s pretty much a wash.

“(I realise that I could do the same by having multiple event strings, but much less elegantly for the user of the API).”

Some users find needing an additional Library inelegant compared to using constants that the IDE will mostly type for them anyway.

“With events, I either have to create and dispatch a different event for each click, or I have to expose those buttons (which opens up all their properties: position, enabled, alpha yada yada) to something that wants to listen for the clicks on them. Or I can bubble the event and do a switch on the target – and again this target means that I have access to set any property of that button.”

Or you can use PresentationModel, and allow the PM to determine the meaning of the gesture (which is roughly equivalent to what you’re doing in Signals, but carries some other functionality as well that you might find advantagous or not).

“(Approaches such as only adding the response handler locally don’t work because you’re then relying on order-of-executions and assuming only one request at a time).”

You might want to look at the way AsyncToken works in Flex and see if that isn’t a better way to handle it.

“I’m intrigued that you’d be so invested in slating an approach that so many people are finding to be useful.”

That’s kind of a harsh interpretation of what I consider a simple discussion of the pros and cons of a specifc technology. But the reason I’m willing to look at the other side of this is the same reason I’m willing to reevaluate the truism that anonymous functions are always bad or any of those other things we’re asked to believe are true.

“Mindful choices allow us to be more intentional in our architecture and implementation.”

Precisely. And for what I’m doing now, at least, the other techniques I am using serve me every bit as well as using As3Signals, without introducing yet another library. I would encourage others to be very thorough in their evaluation of what they get with As3Signals vs. what they lose.

As Rob says, the way functions are treated in AS creates some fundamental weaknesses whenever you use functional techniques, and these are at the core of the problems I have with As3Signals. Personally, I would have preferred that Adobe move addressing these above trying to add multithreading, but they didn’t AFAIK.

Amy – that misses the point. There is a clear conceptual difference between ‘not dispatching’, because the implementation has blocked it, and ‘never relevant’.

I can, of course, choose to have my signal implementation not actually dispatch a particular signal – just as with events – but I can’t choose to listen for a signal which has no relevance to that object.

If I want to, I can listen for a MouseEvent.CLICK on any IEventDispatcher – including a model which has no presence on the display list. I can listen for Video events on an XML loading service. This is broken.

As Rob says, it means when I add a listener to a custom object I often have to start referring to the AS3 reference to check exactly what event is dispatched when by this object.

Even with event hinting, I get very little information to help me figure out – for example – whether there is a progress event dispatched after complete, always immediately before it, or only sometimes immediately before it.

With signals I can create beautifully expressive getters that make this obvious, with very little extra overhead:

progressUpdateBeforeComplete
progressUpdateAfterComplete

(I realise that I could do the same by having multiple event strings, but much less elegantly for the user of the API).

However, my own favourite thing about Signals is using them in composite views. Let’s say our view is a login panel with 3 buttons – ’submit’, ‘quit’ and ‘forgot password’. With events, I either have to create and dispatch a different event for each click, or I have to expose those buttons (which opens up all their properties: position, enabled, alpha yada yada) to something that wants to listen for the clicks on them. Or I can bubble the event and do a switch on the target – and again this target means that I have access to set any property of that button.

With signals I can just add 3 simple signals to the parent view – one for each click.

In my opinion, the signals approach is closer to the kind of ‘need to know’ basis that I want my code to work on. Does the listener need to move these buttons around? Does it need to shift them in position? No – it just needs to know when they’ve been clicked. *If* it wants the buttons to move or change alpha then it should go through an API on the parent.

Personally I still use a mix of events and signals. I’ve done a lot more than ‘play around with’ Signals – I use them in our production code all the time. They are incredibly useful – for example – for implementing a type-safe-at-runtime (ie easy to debug) request-response pattern allowing a specific instance of a class to receive an async update on its own schedule, without having to do horrible hacky workarounds such as arbitrary IDs on events. (Approaches such as only adding the response handler locally don’t work because you’re then relying on order-of-executions and assuming only one request at a time).

I’m intrigued that you’d be so invested in slating an approach that so many people are finding to be useful. Putting all the implementation details aside, there are 3 things we know for sure about signals:

1) They’re the product of an enormous amount of energy invested by numerous very smart people over a long period of time. (Robert hasn’t just been locked in his attic working on a secret master plan).

2) The process of developing them has been done in the open with lots of healthy discussion, debate, testing, heuristic feedback, revision, refactoring, branching (to consider the merits of alternative approaches) and intentional reflection by the community.

3) They offer a different approach to achieving loose coupling between objects, with solutions for some of the problems that have irked many programmers about the AS3 events system.

What’s to object to? Provided A and B are both of high quality, having a choice between A and B is a useful thing IMO. Mindful choices allow us to be more intentional in our architecture and implementation. Even if neither A nor B is perfect, having alternatives with different strengths and weaknesses allows us to optimise.

“Signals has no way for me to be sure that the types on the arguments of my _receiving_ function are the same as what are being dispatched.”

I wouldn’t say “no way.” If that were the case, developers would get frustrated and stop using Signals. Here are three ways people can, and do, have confidence in their listener signatures:

- documentation
- source code
- the code works without throwing a Type Coercion failure

Could it be better? Yes, if ActionScript were improved with generics and stronger function types.

Let me throw this back at Events: How can you be sure your listener Event argument is correct? The compiler certainly doesn’t help you. It takes extra metadata and convention following to achieve this. Personally, with Events I find myself bouncing around asdocs a lot tracking down which constants to use.

“Worse, there is no code hinting.”

The name of the Signal is code hinted, enabling the compiler to guarantee you’re listening to something valid. This is something Events cannot do. However, the Signal signature is not code hinted, due to limitations of ActionScript.

Events only support code hinting when [Event] metadata is used AND kept in sync with the relevant ActionScript AND a specific convention with Event constants is followed. If any of these 3 three stringy links is broken, the chain fails.

AS3 Signals could use metadata to achieve the same level of code hinting as Events. As of yet, though, it’s not something the community has demanded. We seem to manage fine without adding extra stuff that has to be maintained and kept in sync with the real code.