brendan at mozilla.com
Fri Apr 30 17:50:36 PDT 2010
On Apr 30, 2010, at 5:33 PM, Jürg Lehni wrote:
>> 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 did not know about Dojo's hitch, but I believe Mootools' bind is
> not behaving in the same way. It receives an array as a second
> argument, defining the arguments to be passed to the bound
> functions, and appears to ignore any other parameters passed to it
> when calling. I actually prefer this passing of arguments in an
> array over the standardised bind, for reasons explained in my
> previous email.
MooTools takes an array of actual arguments to bind, while the others
take trailing positional actual params, I see. My point was that
however they are passed, these values are bound to the leading
arguments supplied when the bound method is invoked.
> But this means libraries like MooTools automatically break the
> with an incompatible version. And it also is too late for MooTools
> to change that now, as such a change would break all depending code
> at once.
It's an either-or situation. Users of MooTools would have to save
Function.prototype.bind under a different name if they want to use the
original (or prior) value of this (possibly ES5, but perhaps
It's the same drill when mixing libraries. Some cooperate better than
others do, or did -- I believe many can be mixed now without trouble.
In this light, ES5's standard object additions are just another
library that happens to be loaded before any others. This can affect
object-detecting code, certainly. It's not 100% compatible with ES3 on
this basis alone.
But, as you noted about spilled milk, ES5 is a done deal as a
standard, and it is getting implemented. We'll just have to learn from
the experience and keep working to do better.
> This then raises other interesting questions: Should libraries
> refrain completely from polluting any of the default prototypes? How
> else can one be sure there won't be a standardised property in the
> future that might overlap with functionality of a library in such a
Probably. Prototype, I'm told, is not going to change to avoid
extending some built-in core-language prototypes, e.g.
Array.prototype, but it will stop trying to extend DOM prototypes.
Clarification from library authors is welcome here.
>> 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.
> I can only see one library that exactly follows the standard, or the
> other way round; Prototype.js. Dojo's hitch does many other things
> as well, but it might be able to use the native bind now to optimise
> that particular case. MooTools' bind shares the name but behaves
> differently. And jQuery is as always fine as it does not mess with
> the prototypes.
Yes, jQuery nicely avoids the whole prototype issue.
> In this case I get the feeling everybody could have benefitted from
> a Function.bind generic that all the different implementations in
> the prototype could refer to, but nothing standard in the
> Function.prototype object.
It could be that we missed a chance to add Function.bind(callable,
thisObj, argsArray). Adding such a "static method" might have provided
the desired common utility usable without conflicts by libraries. We
may yet add such a Function.bind.
I should mention the spread operator as a way to solve the positional
vs. arrayed arguments issue: http://wiki.ecmascript.org/doku.php?id=harmony:spread
-- no more .apply and .call twinning, no conundrums of the "how do I
apply the new operator" kind.
> At the same time I believe it is also important to understand that
> libraries are good sources of hints for what needs to be improved in
> the language, but not necessarily for how, as such libraries do not
> have the same amount of freedom in the formulation of functionality,
> and often aim for solutions that produce little source code or can
> reuse functionality defined elsewhere in the library. This is then
> not necessarily the right way to implement it natively.
Agreed, and I think TC39 takes this to heart (perhaps more now than
before when the draft standard was being put together ;-).
More information about the es-discuss