Function.prototype.bind

Question

I've got pretty interesting question about EcmaScript-5 Function.prototype.bind implementation. Usually when you use bind, you do it this way:

var myFunction = function() {     alert(this); }.bind(123);  // will alert 123 myFunction(); 

Okay so that's cool, but what is suppose to happen when we do this?

// rebind binded function myFunction = myFunction.bind('foobar'); // will alert... 123! myFunction(); 

I understand that it's completely logical behavior in terms of how Function.prototype.bind is implemented (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind). But in real life conditions it's completely useless behavior isn't it? The question is: is it bug or feature? If it's a bug, why it's nowhere mentioned? If it's a feature, why then Google Chrome with native "bind" implementation behaves absolutely the same way?

To make it more clear, what in my opinion would make more sense, here is the code snippet that implements Function.prototype.bind a little bit differently:

if (!Function.prototype.bind) {     Function.prototype.bind = function() {         var funcObj = this;         var original = funcObj;         var extraArgs = Array.prototype.slice.call(arguments);         var thisObj = extraArgs.shift();         var func = function() {             var thatObj = thisObj;             return original.apply(thatObj, extraArgs.concat(                 Array.prototype.slice.call(                     arguments, extraArgs.length                 )             ));         };         func.bind = function() {             var args = Array.prototype.slice.call(arguments);             return Function.prototype.bind.apply(funcObj, args);         }         return func;     }; } 

So now try this:

// rebind binded function myFunction = myFunction.bind('foobar'); // will alert... "foobar" myFunction(); 

In my opinion, replacing "this" makes more sense...

So what do you guys think about it?

Answer 1

The precedent for Function.prototype.bind was the implementation of the idea in various JS frameworks. To the best of my knowledge, none of them allowed this-binding to be changed by subsequent binding. You might as well ask why none of them allowed this-binding changing, as to ask why ES5 doesn't allow it.

You're not the only person I've heard who thought this odd. Chris Leary, who works on Mozilla's JS engine (as I do), thought it a bit odd, raising the issue on Twitter a couple months ago. And in a somewhat different form, I remember one of the Mozilla Labs hackers questioning if there were some way to "unbind" a function, to extract the target function from it. (If you could do that, you could of course bind it to a different this, at least if you could also extract the bound arguments list to also pass it along.)

I don't remember the issue being discussed when bind was being specified. However, I wasn't paying particularly close attention to the es-discuss mailing list at the time this stuff was hashed out. That said, I don't believe ES5 was looking to innovate in the area much, just "pave a cowpath", to borrow a phrase.

You might possibly be able to propose some introspective methods to address these concerns to es-discuss, if you wrote a sufficiently detailed proposal. On the other hand, binding is a form of information-hiding mechanism, which would cut against its adoption. It might be worth a try to propose something, if you have time. My guess is the information-hiding concern would block a proposal from being adopted. But that's just a guess that could well be wrong. Only one way to find out...

Answer 2

When you bind a function, you ask for a new function that ignores it's own this pseudo argument and calls the original function with a fixed value for this.

Binding this function another time has exactly the same behaviour. If bind would somehow patch in a new this into it, it would have to special case for already-bound-functions.

In other words, bind works exactly the same on "normal" functions as it works on functions returned by bind, and in the absence of overriding factors, it's good engineering to keep the semantic complexity of a function low - it's easier to remember what bind does to a function if it treats all input functions in exactly the same way, as opposed to treating some input functions specially.

I think your confusion is that you view bind as modifying an existing function, and you therefore, if you modify it again you expect the original function to be modified again. However, bind does not modify anything, it creates a new function with specific behaviour. The new function is a function in it's own right, it's not a magic patched version of the original function.

As such, there is no mystery on why it was standardised or invented the way it was: bind returns a function that provides a new this and prepends arguments, and works the same on all functions. The simplest possible semantic.

Only this way is it actually safe to use - if bind would make a difference between already bound functions and "normal" ones, one would have to test before binding. A good example would be jQuery.each, which passes a new this. If bind would specialcase bound functions, there would be no safe way to pass a bound function into jQuery.each, as this will be overwritten on each call. To fix that, jQuery.each would have to specialcase bound functions somehow.