On 1 May 2010 11:16, Jürg Lehni <li...@scratchdisk.com> wrote: > > Also, could you show me a real world use case of the argument concatenation > feature found in hitch and bind? I am not working with Prototype nor Dojo, > but so far I have not come to face a situation where this would have been > useful. The resulting code seems rather confusing to me, very hard for > someone else than the writer to figure out what is actually going on. >
Coming from languages where 'this' is easily thought of as an implicit first function argument, bind() starts to feel more elegant. It has similar counterparts in Python (functools.partial()), C++ (e.g. std::bind<>, boost::bind<>), perl (sub::curry), and so on. Two major advantages to pre-pending arguments are to specialize an existing function or algorithm for a particular use case (e.g. to make a generic function conform to a particular interface for some library/API, or e.g. given some complex sorting function, currying its initial arguments which are parameters that control its behaviour, leaving the last 2 for Array.prototype.sort() interface), and as an ad-hoc means of passing arbitrary data between continuations without requiring more than an argument list specification as the 'contract' between either side (say, instead of an additional object whose property names and types are agreed on and specified in some way). There are many more real-world use cases for partial function application, although perhaps they're a little hackier, e.g. having a particular function-with-argument-list be called in response to a DOM event, by pre-populating all its expected arguments and having it simply ignore the extraneous Event object. This could either be a single line of code with bind(), or a more verbose anonymous function covering 1-5 or more lines of code depending on your style. Another reason for supporting this in the language is that it is currently expensive (in SpiderMonkey and JavaScriptCore at least) to clone and modify an argument list from within JavaScript; removing partial function application is a great way to speed up loops. It would be nice if native code had the chance to intervene instead, because this functionality is not going away from the libraries any time soon, nor is the demand from users. David > > Jürg > > On 1 May 2010, at 06:21, Alex Russell wrote: > >> On Apr 30, 2010, at 5:33 PM, Jürg Lehni wrote: >> >>> 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. >> >> Libraries that extend intrinsic prototypes deserve any and all pain that >> comes to them. Their users should likewise be warned of the impending pain; >> but no affordance should be made for their poor decision making when it >> comes to designing a better API for users of the language. >> >>> This then raises other interesting questions: Should libraries refrain >>> completely from polluting any of the default prototypes? >> >> Yes, absolutely, 100%. >> >>> 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? >> >> And why is that the language's job? As a library author, the goal for me of >> a library was always as a stop-gap until the cavalry arrived. Now that >> they're showing up, I'm glad to un-plant my flag and cede the high ground to >> the committee. >> >>>> 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. >> >> Dojo's hitch doesn't touch prototypes. With non-intrinsic-munging libraries >> do is between them and consenting users. It's only libraries that are >> foolish enough to extend intrinsics that are at any risk here, and as I >> said, they deserve it. >> >> Regards >> >>> 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 >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> >> -- >> Alex Russell >> slightly...@google.com >> a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
