Function.apply not using thisArg parameter

Question

I'm writing some Actionscript3 code that attempts to apply a method to an object that is determined at runtime. The AS3 documentation for Function.apply and Function.call both indicate that the first argument to those functions is the object which will be used as the 'this' value when the function is executed.

However, I have found that in all cases when the function being executed is a method, the first parameter to apply/call is not used, and 'this' always refers to the original object to which that method was bound. Here is some example code and its output:

package
{
    import flash.display.Sprite;    
    public class FunctionApplyTest extends Sprite
    {
        public function FunctionApplyTest()
        {
            var objA:MyObj = new MyObj("A");
            var objB:MyObj = new MyObj("B");

            objA.sayName();
            objB.sayName();

            objA.sayName.apply(objB, []);
            objA.sayName.call(objB);
        }
    }
}

internal class MyObj
{
    private var _name:String;
    public function MyObj(name:String)
    {
        _name = name;
    }   
    public function sayName():void
    {
        trace(_name);
    }
}

Output:

A
B
A
A

A minor modification to the above code to create an in-line anonymous function which refers to 'this' shows that the correct behavior occurs when the function being applied/called is not a bound method.

Am I using apply/call incorrect when I attempt to use it on a method? The AS3 documentation specifically provides code for this case, however:

myObject.myMethod.call(myOtherObject, 1, 2, 3);

If this is indeed broken, is there any work-around besides making the target methods into functions (which would be quite ugly, in my opinion)?

Accessible

I'm going to have to say that you're doing something extremely wrong if you need this kind of coding. What exactly are you trying to accomplish by doing this? – Stoss

Tested it on my end. seems like a bug. Try searching in the JIRA: bugs.adobe.com/jira/browse and if you don't find it, submit it – Catarina

its not a language bug, but poorly written documentation – Vaughn

Answer 1

Its not a "bug", but the documentation for call and apply is very misleading and doesn't do a good job at all of explaining whats going on. So here is an explaination of what is happening.

Methods are different from Functions in ActionScript. Methods are defined as a part of a class defintion, and methods are always bound to that instance. See the Methods second of this link. To quote from there:

Methods are functions that are part of a class definition. Once an instance of the class is created, a method is bound to that instance. Unlike a function declared outside a class, a method cannot be used apart from the instance to which it is attached.

So when you make a new instance of MyObj, all of its methods are bound to that instance. Which is why when you try to use call or apply, you aren't seeing this getting overridden. See the section on Bound Methods for details.

See, this document for an explanation of the traits object, which actionscript uses to resolve methods and used for performance reasons behind the scenes is probably to blame. That or class methods are just syntactic sugar for the following ECMAScript pattern:

var TestClass = function(data) {
    var self = this;
    this.data = data;
    this.boundWork = function() {
        return self.constructor.prototype.unboundWork.apply(self, arguments);
    };
};

TestClass.prototype.unboundWork = function() {
    return this.data;
};

Then:

var a = new TestClass("a");
var b = new TestClass("b");

alert(a.boundWork()); // a
alert(b.boundWork()); // b

alert(a.unboundWork()); // a
alert(b.unboundWork()); // b

alert(a.boundWork.call(b)); // a
alert(a.boundWork.call(undefined)); // a

alert(a.unboundWork.call(b)); // b

or even more interesting:

var method = a.unboundWork;
method() // undefined. ACK!

Vs:

method = a.boundWork;
method() // a. TADA MAGIC!

Notice that boundWork will always get executed in the context of the instance it belongs to, no matter what you pass in for this with call or apply. Which, in ActionScript, this behavior is exactly why class methods are bound to their instance. So no matter where they are used, they still point at the instance they came from (which makes the actionscript event model a little more "sane"). Once you understand this, then a work-around should become obvious.

For places where you want to do some magic, avoid the ActionScript 3 based hard-bound methods in favor of prototype functions.

For example, consider the following ActionScript code:

package
{
    import flash.display.Sprite;    
    public class FunctionApplyTest extends Sprite
    {
        public function FunctionApplyTest()
        {
            var objA:MyObj = new MyObj("A");
            var objB:MyObj = new MyObj("B");

            objA.sayName();
            objB.sayName();

            objA.sayName.apply(objB, []); // a
            objA.sayName.call(objB); // a

            objA.pSayName.call(objB) // b <---
        }
    }
}

internal dynamic class MyObj
{
    private var _name:String;
    public function MyObj(name:String)
    {
        _name = name;
    }   
    public function sayName():void
    {
        trace(_name);
    }

    prototype.pSayName = function():void {
        trace(this._name);
    };
}

Notice the declaration difference between sayName and pSayName. sayName will always be bound to the instance it was created for. pSayName is a function that is available to instances of MyObj but is not bound to a particular instance of it.

The documentation for call and apply are technically correct, as long as you are talking about prototypical functions and not class methods, which I don't think it mentions at all.

Vaughn

Thank you very much for explaining this, it was highly enlightening! I think it is probably not the case that method declaration is syntactic sugar for your first code example, because if that were true then ClassType.prototype would have properties on it for each of the unbound methods. To me it seems like that would be the best of both worlds, somewhat similar to Python's mechanism where objA.sayName() is syntactic sugar for MyObj.sayName(objA) . – Accessible

Answer 2

Wow this is very surprising O.o

Tested it on my side as well and tried to pass in parameters as well and in all cases, the passed thisArg doesn't seem to be used at all (clearly seems like a bug to me).

I had to use something similar but had the additional constraint of needing to access the method without creating an instance of the object (which is possible in other languages but not in AS3 >.<). So I ended up creating static functions and passed my own "thisArg" instead.

So making static functions instead is a possible workaround :

static public function SayName(thisArg : MyObj) : void
{
    trace(thisArg._name);
}

Not the greatest since you'll probably end up doubling code like this >.<

Alternatively, if the methods are public, you can save the function's name instead of the function and access it's method by doing something like :

var funcName : String = "sayName";
objB[funcName].apply(null, []);
objB[funcName].call(null);

However, this is limited depending on the scope of your method (public methods can be used like this from everywhere, internal methods within the same package as your class and private methods from inside the class only). So it is more limiting than using the actual Function instance of your method which can be used from anywhere.

This seems like a pretty nasty bug O.o I hope someone else has a better solution to this.

Cindacindee

Answer 3

Have you tried actually using the this reference explicitly, i.e.:

internal class MyObj
{
    private var _name:String;
    public function MyObj(name:String)
    {
        _name = name;
    }   
    public function sayName():void
    {
        trace(this._name);
    }
}

It might just be that when the this keyword is omitted, the original instance is used to look up the field/variable, whereas what thisArg really does is to re-bind the this keyword. If that's the case it's arcane at best, but it might be worth a try.

Theatheaceous

+1 thisArg does re-bind this. I've found the Array docs to to provide some similar examples of this behavior. – Hindrance

Yes, I also tried with using the 'this' keyword explicitly, and unfortunately found the same behavior. The documentation for Array.filter linked above explicitly says the 'thisArg' parameter must be null if the callback function is a method, so it seems that the implementer of filter also ran into this issue. – Accessible

Answer 4

.call() on a prototype property (a function) worked fine, 'this' was as provided at the call site. nice answer. But note that access modifiers (public, protected) are respected, so if you are calling into a different class, you will not be able to access protected members (naturally).

Transitive