Come with me as I chase more windmills.
flash.events.EventDispatcher could be easier to clean up
removeAllEventListeners(), where are you? Everyone's been looking for you.
And wouldn't it be great if I could mark some listeners to be removed automatically the first time called?
Whatever, this is OOP, it shouldn't be too hard to subclass and do it myself.
Let's create a new class, override addEventListener() and...
flash.events.EventDispatcher is difficult to extend
Oh snap, looks like my subclass can't access all those listeners in EventDispatcher.
Guess I'll maintain my own array of listeners so I can remove them all easily. It's been done before:
But now my array has strong references to all the listeners. The useWeakReference option won't help me now.
Ohhh, I know!
Dictionary can haz weak references?
Unfortunately, though, storing methods in a weak keys Dictionary is buggy.
Besides, Dictionary has no concept of order.
What if I need to know what sequence the listeners are in?
Would I create a weak reference Dictionary for each listener and have an array of dictionaries?
It's been done, but I'm not going to consider that until the Dictionary bug is fixed.
Hmm... Can haz special array with weak references? Keep dreaming.
The point being, flash.events.EventDispatcher is a black box--the frustrating kind. Adobe Flash Player engineers, if you're reading this and you know a magic namespace to open up the listeners, please let me know. While we're dreaming, how about a look at the source code for EventDispatcher?
Oh well, at least we have the IEventDispatcher interface. It seems like a lot of work, but I should be able to write my own dispatcher from scratch and satisfy the interface, right?
IEventDispatcher cannot be implemented
Not entirely true. It can, but not with pure AS3. But I don't know that yet.
So I work away building my own implementation of IEventDispatcher. I'm adding listeners, I'm removing listeners, I'm even removing all listeners! Things are looking up.
I'm at the exciting part now: the dispatchEvent() method. Ok, find the listeners array for the event type, good, good. Now I'll just set the event.target property to this and iterate through the--
Event.target is read-only
I can picture the meeting in the secret DOM Level 3 Dungeon:
Level 3 Paladin: "Would anyone ever need to change the event target?"
Level 3 Seer: "Inconceivable!"
But, there must be some way of changing the event target, right?
IEventDispatcher cannot be implemented without using EventDispatcher
You see, flash.events.Event has a secret alliance with flash.events.EventDispatcher.
Only EventDispatcher is entrusted with the awesome power to change target.
We're so much safer that way.
And yes, you will have to extend flash.events.Event because there is no event interface.
Here's an offer you can't refuse: implement an interface using one special implementation of that interface!
You can write your own dispatcher if you like, but if you have a hang-up about target and currentTarget being null all the time, you'll have to instantiate EventDispatcher and have it dispatch the event for you. Which means it will need all your listeners and your Gmail password. Which makes you wonder why you even bothered.
I hope this gives a sense of the obstacles that arise when trying to extend the AS3 event system. It fights you at every turn. Please let me know if I've overlooked or misunderstood anything.
At least this article was fun to write. It solidifies my rationale for building and using my own event system when I don't need to integrate with the display list.