arrows and a proposed softCall

Herby Vojčík herby at mailbox.sk
Tue Jun 5 11:34:18 PDT 2012



Angus Croll wrote:
> 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

The second, of course :-)

Herby

> On Tue, Jun 5, 2012 at 10:23 AM, Brendan Eich <brendan at mozilla.com
> <mailto:brendan at mozilla.com>> wrote:
>
>     Russell Leggett wrote:
>
>         On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich
>         <brendan at mozilla.com <mailto:brendan at mozilla.com>
>         <mailto:brendan at mozilla.com <mailto:brendan at mozilla.com>>> 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
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/__listinfo/es-discuss
>     <https://mail.mozilla.org/listinfo/es-discuss>


More information about the es-discuss mailing list