arrows and a proposed softCall

[Angus Croll]

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 <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>> 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
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120605/1f59f2f3/attachment.html>