Tag Archive for 'Dispatching'

Lately there was a lot of attention in English-speaking Flash community to Robert Penner’s AS3 Signals library. I’m surprised because there’s nothing revolutionary and even new in this approach. Yes, this concept is good in special cases. And yes, I agree that Flash events are ugly.

First of all, if you don’t know what I am talking about take a moment to check the library on the web.

Second, read my previous post about silent developers and flash community.

Well, every flash developer earlier or later starts thinking about Flash events system. Events are in the core of ActionScript 3.0 but you might consider their implementation ugly. I’ll be referring to Robert’s post one and post two. Where he says that:

• addEventListener syntax is awkward

  public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void

  I agree that useCapture is only needed for DisplayObject events, but I disagree that useWeakReference should be widely used. This is bad practice adding stuff and hope that it will be somehow magically removed later. You must always unsubscribe manually.

• He doesn’t like Event class properties and methods related only to DisplayObject events. But is having 2 event systems better?
• There should be additional methods like addOnce() or removeAllListeners(). Every experienced developer has already written helpers for these actions. If not more.
• It is not possible to implement IEventDispatcher without using an EventDispatcher object. Yes, trying to extend Flash events model is hard. In fact I saw an implementation of event bubbling through a tree of special objects (which are not DisplayObjects) which mimics standard event bubbling behavior. The code is full of dirtiest hacks I’ve ever seen.

After, Robert proposes his own events model. I’m not saying that the idea is bad. No, it has its pluses and might be used in a couple of small projects. Flash developers are tied to using events by design. Signals and wrapping events just don’t magically solve problems. As I mentioned before, most of experienced Flash developers wrote their helpers and some of them even developed bubbling mechanisms for objects other than DisplayObject.

Flash events are too simple when used out of display list and has some unused code, that’s correct. But they shine if used within display list. Especially if you develop interfaces. Bubbling, capture phase, canceling and stopping events — these are very convenient tools. A lot of the times I find myself catching children events in some common “root” object, for example.

Yes, Signals are simple. But try adding bubbling, phases, canceling and stopping functionality to them and you’ll get plain old Events. Let’s check what else Robert says on the site.

• Removing unnecessary code feels great.
  You just remove one code adding another.
• Composition and interfaces are favored over inheritance. Events in interfaces are a good thing.
  I don’t see this as advantage, events are usually registered with [Event] metatag so Flex Builder can use autocomplete. From numerous public properties I have to find a Signal object I need.
• Event types are classes, not strings.
  OK, while you don’t have other properties Event class provides you are good. What will you do when you need target, currentTarget and others? Oh, I missed the DeluxeSignal class. Looks like you are going back to Event object. Event types are not only strings either in Flash events. Event type is a class extending Event class + event name.
• Event classes should focus on the data they contain, not on who sends them.
  Event class contains just enough information listeners need. Consider it an e-mail. What Signals dispatch looks more like huge boxes with different stuff. Do all your listeners need all that?
• Event classes should not contain string constants that various other classes use.
  Who said that?
• So far, not a single “static” keyword in the source.
  Static event names are not mandatory, they are used for compile time checking. Consider your own example:

  progress.dispatch('The Answer', 42); // will succeed

  If you pass some kind of a name here you’d create a static constant for it too. In case you mistype it.

I agree that releasing code is good, I agree that using Flash events out of display list might look like shooting flies with a turret, but I don’t understand why people are so excited. Once again,

1. Experienced Flash developers have created their own helper classes long time ago
2. Signals are good while they are simple
3. Some of pluses mentioned are questionable
4. I doubt we need 2 event mechanisms and wrappers between them

This is more like a toy.

And last, a lot of people use events wrong. That’s where stuff like data:Object properties in custom events come from.