Brendan, Thank you for clarifying.
> 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. But this means libraries like MooTools automatically break the JavaScript standard, as now Function.prototype.bind gets overridden 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. 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 way? > 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. 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. Such a Function.bind could then have been defined to receive the arguments in one array object, and to concatenate them with the ones passed to the returned function when calling. This would have allowed all the different implementations mentioned above to use it in an efficient way. But I guess there is no point crying over spilled milk, and I agree, it is better to have the current Function.prototype.bind than nothing at all. 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. Jürg _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
