Extending the AS3 Event Pattern
Extending the AS3 Event Pattern, Posted in Actionscript 3, March 5th, 2009

I am a big fan of Signals/Slots and the Messaging Paradigm used by Cocoa. Since neither can really be implemented flawlessly in AS3(without some major potential performance issues down the road). I came up with a Hybrid Event Pattern solution I call the “Juki Event Pattern(JEP)”. Here is a PDF document outlining the pattern.

The major difference between JEP and the one adopted by Java/Flash is the fact that the events are exposed as public getter functions. This leads to whole new worlds of interface-required events. However, the pattern maintains full backwards compatibility with the built-in event pattern. JEP is an extension of the basic event pattern and requires a IEventDispatcher for the purpose of carrying out the actual dispatching.

A simple interface is used to “connect” a listener function or event to another event. Yes, I said you can connect one event to another. Also because the events are exposed as a public getter you could essentially wrap another event from a asset class and expose it as your own.(think about that for a moment). I have provided three connection options: “connect”, “connectAsSilent”, and “connectAsPassThrough”. Respectfully the operations are basic connect: where the event object is passed to the listener, where nothing is passed to the listener, where all arguments of the dispatch() method are passed to the listener.

Full disconnect.  As requested, I have provided the ability to disconnect from all listeners.  I also maintain a list of the listeners in a soft-linked Dictionary object.  This was also another request that I ended up finding useful for internal uses.

Dispatch log.  I made a decision early on that my primary problem with the default event pattern is that there is no way to tell if any specific event has already dispatched.  The problem here is sometimes a event only fires once.  Say, If it represents a “download complete”.  It fires once, if you fail to catch it, your screwed.  Normally, I’d say, check your code try to catch it earlier.  What if that wasn’t possible tho.  I maintain a array of the last arguments passed to the event and if it has dispatched yet.  Sadly, for memory purposes I have chosen not to capture dispatches outside of the JEP.  I may implement this as a “use as your own performance risk” feature later.