I use mx.utils.Delegate.create constantly, however in looking at the source code, there are some memory inefficiencies. In the create method, there is a function literal (the var f). By creating this function literal, the create method is actually prolonging the scope of it’s arguments and it’s local variables in the scope of f for the lifetime of f. So what does all this mean? Well, it means that in the scope of f you have create’s argument’s obj and func still available. Yet, f reference’s these values by creating local variables from static properties attached to the function itself, instead of accessing them directly.

Therefore, the assignments of the properties to f:

f.target = obj;
f.func = func;

and the local variables of f

var target = arguments.callee.target;
var func = arguments.callee.func;

are like making multiple assignments of the same variable

var target1:Object = new Object();
var target2:Object = target1;
var target3:Object = target2;

To be more efficient, the create method could simply be rewritten to use the create arguments in the scope of f:

static function create(o:Object, f:Function):Function
{
        return function()
        {
                return f.apply(o, arguments);
        };
}

This information is important to note only if you have use the mx.utils.Delegate.create heavily.

[UPDATE]
Since I use my own class instead of the mx.utils.Delegate, I hadn’t modified it directly. In doing so, I found out there was a a confusion on the which scope func was in, since it was defined as a private instance var as well. This definition creates conflict with the argument func of the create method. Therefore, the vars need to be named different. This is good practice anyways and it eliminates this conflict. I changed the create method definition above to reflect this.