Changing The Execution Context Of JavaScript Functions Using Call() And Apply()

Articulated perfectly for me. This is one of those concepts thrown around quite a bit at the jqcon sessions that I knew I needed to understand, and *sort of* did, but this post really gelled it together for me.

So thanks.

I guess my next gray area would be when/why to use call() vs. apply(). If I figure that out I'll report back.

This is the most sense

call

and

apply

ever made. Great post!

@Ben, oh yeah, that. I wasn't expecting that. Ah well. :P

Very helpful, the part I do not quite understand is this one :

// Now, let's set the test method as an actual property
// of the object A.
objectA.testContext = testContext;

Why do this and what does happen. It seem to have no effect.

This is an interesting concept to me. Made sense just not really able to picture what I would use this for yet.

@Ben,

.call reveals so much about JS. Every function has it defined, but .call itself is a function. So that means .call.call is defined. And .call.call.call. It's not just theoretical. I've tried it. It's true in all browsers.

What does this mean? It means the .call doesn't actually exist until you call it into existence by referencing it. (That seems like it might be a pun, but I don't think so.)

It HAS to mean that though. Otherwise, the first function you define would result in an infinite loop in the interpreter, as it kept defining more and more .call methods of .call methods.

And all JS functions are "higher level functions", capable of accepting functions as arguments and returning functions as results (as in currying). That means that, if func returns a function, func.call(...).call exists too. But only when you call it.

This stuff makes me feel like John Forbes Nash when he used to let his mind get caught in tight loops of numerological analysis of friends' social security numbers.

I've only recently discovered:

if (!Function.prototype.bind ) {
	Function.prototype.bind = function( obj ) {
		var slice = [].slice,
			args = slice.call(arguments, 1),
			self = this,
			nop = function () {},
			bound = function () { return self.apply( this instanceof nop ? this : ( obj || {} ), args.concat( slice.call(arguments) ) ); };
		nop.prototype = self.prototype;
		bound.prototype = new nop();
		return bound;
	};
}

https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind

it can be used to bind a function to a certain context (obj parameter), so when you call the function it always executes in that context.

@WebManWalking

I've never thought about .call.call before. I tried it after reading your comment. I believe however that it is actually a circular reference and not that it doesn't exist until you call it. All objects in JS are passed by reference and functions are objects. Consider:

var foo = {};
foo.foo = foo;
 
console.log( foo.foo.foo.foo /*...*/ );

As in .call.call, foo.foo just points back to itself.

@Ben

I really enjoyed your previous post on changing the this context of self executing function blocks. I've not considered that before. Very interesting stuff. Thanks for that and many other gems here on your blog.

In most cases I find I need to get a local reference to this within a method for places where context is lost (ie... within a callback). If this is just an object literal that has been created to pass into the block as the context, I think I'm better off just using a local variable and not leveraging the this context.

var foo = ( function () {
 
	var self = {};
 
	self.someProperty = ...
 
	self.someMethod = ...
 
	return self;
 
}());

or as an argument

var foo = ( function ( self ) {
 
	...
 
	return self;
 
}({}));

versus

var foo = ( function () {
 
	var self = this;
 
	...
 
	return self;
 
 
}).call({});

I think self is just as readable as this and self will obfuscate where as this will not.

On another note, in your post above you say all functions are actually methods and all belong to an object, but this is not actually true if declared within a closure.

function doSomething () {
 
	var foo = function () {};
 
}

or ( same result )

( function () {
 
function foo () {}
 
}());

These examples belong to the local execution scope of their respective closures but not an accessible object.

@nelle

The script you posted is capable of currying a function as well. It can accept additional arguments and apply them as well as the context. If you want a script that only binds the this and doesn't have the additional overhead, you could use:

function fnBind ( context, fn ) {
	return function () {
		return fn.apply( context, arguments );
	};
}

or on the prototype

Function.prototype.bind = function ( context ) {
	var fn = this;
	return function () {
		return fn.apply( context, arguments );
	};
};

Also I've been trying to wrap my head around the nop and bound prototype use in the script you posted. It seems like it is an attempt to make it safe to bind constructors. I don't know of a use case for that. Can anyone else think of one?

@Bob What you have for the Bind is wrong.
here is the right way of doing it

Function.prototype.bind = function( context ) {
	var args = [].slice.call(arguments,1),
	fn = this;
	return function () {
	return fn.apply( context,args );
	};
};

so in this case this will return a new function and changes the scope. which is different from call and apply.

@Ben
@Bob
We can say All functions in the Global Scope are Methods :)

@mahdi,

Neither snippet is right or wrong. Your example will bind the context as well as arguments. Mine will only bind the context.

If you're not passing additional arguments beyond the context ( which I often don't ), there is no need to slice the arguments. If you wish to bind arguments as well, I would use something similar to nelle's post. It will allow for partial application by concatenating additional arguments on execution of the newly bound function. Your example will not. Assuming the function in your example is not reaching to any outer variables, it will always have the same result which isn't very flexible.

As Ben states in the above post the difference between call and apply is only in the method signature.

@Bob

I am not passing extra arguments don't get confused I am passing the arguments that the function expects to get.

Function.prototype.bind = function( context ) {
var args = [].slice.call(arguments,1),
fn = this;
return function () {
	return fn.apply( context,args );
};
};
 
 
 
function test(a,b,c){
return a+b+c;
}
var newTest = test.bind({},1,2,3);
newTest(); //returns 6 ( NO PARAMETER HAS BEEN PASSED TO newTest )

but in your code arguments in sencond function is an empty array cause you are loosing the reference :)

I hope this made it clear for you

Ben, thanks for taking the time to document this!

Personally, I like more the first post since it is more like application of the theory described in the second.

The only thing that I see a little misleading is the title. "Changing The Execution Context…" sounds like we are changing the whole context. As you most probably know the execution context have three major properties - variableObject, scopeChainArray and thisObject. You are talking only about changing its third property.

For those who don't know this check out the amazing article by Dmitry Soshnikov at http://dmitrysoshnikov.com/ecmascript/javascript-the-core/#execution-context

//Plamen

Your first two code examples don't actually include the 'this' keyword, although your explanations indicate that they do:

==========================================

sarah.sayHello();

... the "this" keyword within the sayHello() method is a reference to the sarah object.

Similarly, in this code:

getScreenResolution();

... the "this" keyword within the getScreenResolution() function is a reference to the window object (since unbound functions are implicitly bound to the global scope).

Is there any way to achieve similar functionality in Coldfusion? I need a way to call() or apply() in Coldfusion as well to dynamically bind my 'this' variable.

Great!! Great!!! Great!!! ... especially your graph, It explains everything. I came back here few times writing "JavaScript - call() and apply()" at http://blog.i-evaluation.com/2012/08/15/javascript-call-and-apply.Very useful post. Thanks a lot!

Very well written. Simple and to the point. There are so many blogs around by many experts but none did such a good job of explaining the context as yours in my quick google search.

Thanks, and I am back to my coding now.