Delegates,be careful....

I have been noticing alot of code samples around the web that features actionscript code that looks like the following:


myComponent.addEventListener( "someEvent" , Delegate.create( this , someFunction ) );

Delegates are extremely powerful tools, and I use them frequently, but through experience I must say that in my eyes, the above is not good form when building a Flash application. My qualms are up for debate here, so I am inviting anyone to toss in their 2 cents.

First off, I have always had an issue with the way Delegate.create has been created. I had a little pow wow with Stacey about it a month or so ago. The problem is the fact that it asks you to pass an actual reference to the function in question:

Delegate.create( this , someFunction );

To me this is an issue because if for some reason someFunction is overwritten at runtime (which is common in AS) then your delegate no longer refers to the correct function. I cannot think of one case where storing the function reference would be advantageous.

I rewrote Delegate to look like this:

Delegate.create( this , "someFunction" );

This simple change allows you to overwrite the target function and still have Delegate call it correctly.


Now on to addEventListener. Everytime I see the following it gives me shivers:

myComponent.addEventListener( "someEvent" , Delegate.create( this , someFunction ) );

On large scale Flash applications this would be your doom. You would be asking for some serious memory leak action if you had an application that changed states frequently.

The issue with it in my mind is that it provides no mechanism for removing these listeners! On a small scale 1 form application this is surely tolerable, but many Flash applications of any level of complexity place and remove items frequently, making this a disaster waiting to happen. Consider the Stage object. It is global, and often you would be making items listen to it's events for resizing and the like. Would you add listeners to it in this fashion? If the answer is yes then you are going to have a real problem one day.

I guess people are thinking that if they use these with UIcomponents, then if the UI component is removed the Delegate will be garbage collected. That is true, but the scary thing is that if you start coding that way in a big project, you start getting into issues like this:

managerClass.addEventListener( "someEvent" , Delegate.create( this , someFunction ) );

By managerClass, I am refering to something that does not get removed from stage, or some kind of global object or perhaps a singleton. This is where there is major potential for problems. You are introducing the oppourtunity for the application to add duplicate listeners, and on top of that providing no facility to remove them other than going directly to the listeners array of the dispatching object.


So my suggestions are the following:

1/ Use listener objects in which a reference remains in the scope of where it was applied as a listener. It is likely that if it is to be removed then it will be removed in that scope. It may seem like more work but it will help you avoid memory leak issues.

2/ Extend EventDispatcher to accomodate callbacks. The default implementation does not allow you to do this, but there are others that do. One I can think of is gDisptacher by Grant Skinner


So in final I am just highlighting a few concerns regarding Delegates, because it can be easy to get carried away with Classes as helpful as it is.