arrows and a proposed softCall

[Brendan Eich]

Russell Leggett wrote:
> On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich <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