Yes the thread needs wrapping up. Maybe I can attempt summarize the dilemma - with a question:
Is call/apply just a remedy for non-lexical this assignment? Or is it a powerful feature in it own right. I'm with the second camp, but I think I'm in the minority in this list On Tue, Jun 5, 2012 at 10:23 AM, Brendan Eich <[email protected]> wrote: > Russell Leggett wrote: > > On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich <[email protected]<mailto: >> [email protected]>> wrote: >> >> >> What I perceive from the JSFixed effort, and from Angus who is >> good enough to post here: people have a particular concern that >> fat-arrow is too sweet and it will lure the children into the >> witch's house: passing fat arrows to dynamic-this APIs. >> >> We have data suggesting that fat arrows address the dominant >> use-case, thanks to Kevin Smith and others. So fat arrows are in >> ES6, well and good. >> >> I think the particular concern about => being an attractive >> nuisance for some APIs such as Angus's mixin combinators, which >> rely on .call overriding |this|, can be addressed by adding -> >> too. Angus agrees, but -> is not on the boards for ES6 (yet). >> >> We could try to revive ->, but first, we should face the >> attractive nuisance argument squarely, instead of dancing around >> it with isBound abuses that try to "catch fat arrow going into the >> witch's house". >> >> >> I think that with ->, a similar problem will still crop up - specifically >> that => will be the more common use, and then in the rare case that -> is >> needed, people may still use =>. >> > > I agree. The problem we'll then see is anxiety over "which arrow?" -- the > Paradox of Choice (Schwartz). > > > Do we still need isBound to catch that error as well? Even with the >> choice of -> or =>, the person writing the code has to know which one to >> use and why. That means they have to understand the whole dynamic |this| >> problem. >> > > Agreed, so (while we are spiraling, no worries) this helps. We cannot > remove the dynamic vs. bound |this| choice from JS. But we can avoid adding > choice when shortening, based on use-case frequency analysis. This, we have > done (many thanks to Kevin Smith again), and it is why => got into ES6. > > > I think that the dynamic |this| behavior of jQuery is not something that >> should be encouraged. I understand it is probably mostly that way because >> of the dom event api, >> > > JQuery goes further, I think simply due to mimesis. The DOM binds |this| > to the event target but in the context of the old DOM level 0, where the > only way to attach an event handler was as a method of the target, this was > not "wrong". JQuery goes much, much further down the path to crazy |this| > dynamic binding. > > > but that doesn't change the fact that it really has a bad smell to it. >> > > On this everyone agrees. No disrespect to JQuery, but it is important to > know what *not* to imitate. We know now, so we shouldn't be using JQuery as > a rationale for dynamic-this short forms or isBound as a general tool. > > > CoffeeScript has ->, but if you look at the examples, none of them >> actually make use of dynamic |this| except for methods, and we're adding a >> nice method syntax, so it isn't really needed. Method syntax, and => should >> cover the majority of cases and lead people down the right path. >> > > This is the current ES6 state and rationale, indeed. > > > I know this is going around in a circle, but my point is that adding -> >> doesn't fix the problem, which is devs not knowing when to use => and when >> to use function. >> > > It's a good point. I hope we can wrap this thread up. It has been helpful > to disclose or emphasize the situation: > > 1. "soft-bind" breaks abstractions and won't fly with implementors. > > 2. isBound needs more discussion but it too breaks abstractions and it > must be defined (Mark's definition) to work for all this-insensitive > functions. > > 3. => covers the dominant use-case for functions not using |this| and > functions capturing lexical |this| via .bind or var self=this. > > 4. Adding -> doesn't avoid confusion over whether to use => or function, > it only adds a shorthand -- good for those who want this -- and at the same > time (the paradox of choice) creates anxiety over "which arrow do I use?". > > We could add isBound. We could add -> too. Right now ES6 has => only, > based on a weighting of the costs and benefits in 1-4. > > > /be > > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
