Function.prototype.bind

Brendan Eich brendan at mozilla.com
Fri Apr 30 16:58:51 PDT 2010


On Apr 30, 2010, at 6:32 AM, Jürg Lehni wrote:

> After having used my own version of an implementation of  
> Function.prototype.bind for about 4 years now I recently became  
> aware of the one that appears to now be standardised in ES5.
>
> The following page suggests its definition stems from the  
> Prototype.js library: <http://wiki.ecmascript.org/doku.php?id=proposals:static_generics 
> >
>
> The page argues that "if we do this, we should emulate Prototype,  
> including its 'pre-args' feature, since it actually hacks on  
> Function.prototype and it's a de-facto standard".
>
> I have to disagree, especially with this so-called 'pre-args'  
> feature, which prepends arguments to the final argument list. There  
> are quite a few libraries out there, Prototype.js is only one of  
> many, and seems to have lost significance over the past years.  
> Calling it a de-facto standard and shaping parts of the future  
> ECMAScript standard after it in order to remain compatible with it  
> seems questionable.

It's a fair point. Perhaps we prematurely standardized  
Function.prototype.bind.

But did you know that Dojo's hitch also allows leading arguments to be  
bound too? Likewise MooTools's bind. Only jQuery's proxy does not.

I always say that it is early days in the JS library standardization  
process, and we should not prematurely standardize. Nevertheless I  
think ES5 is better off with Function.prototype.bind than without. We  
could have done nothing to serve this use-case, but that seems  
strictly worse. We could have done something else but it would have  
been under a different name.

Instead we went with what seemed the de-facto standard. It's still a  
point in common among several top libraries.


> There are other areas were similar considerations seem to have  
> played a role, the oddly named Object.keys() comes to mind.

We've covered this recently. It was one of Doug Crockford's  
suggestions, IIRC. I like Doug's generally shorter names, but it  
indeed does not fit with Object.getOwnPropertyNames. This is a design- 
by-committee artifact, IMHO. We'll try to do better in the future in  
unifying name styles.

/be


More information about the es-discuss mailing list