arrow function syntax simplified

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Mon Apr 2 13:19:09 PDT 2012


On Mon, Apr 2, 2012 at 12:47 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Douglas Crockford wrote:
>
>> On 4/2/2012 8:24 AM, Brendan Eich wrote:
>>
>>> Jorge wrote:
>>>
>>>> I saw it
>>>> here:<http://www.yuiblog.com/**blog/2012/03/30/what-is-the-**
>>>> meaning-of-this<http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this>>
>>>>
>>>>
>>>
>>> Right -- I think Doug was remembering the "Harmony of My Dreams"
>>> sharp-functions
>>> (http://brendaneich.com/2011/**01/harmony-of-my-dreams/#**
>>> sharp_functions<http://brendaneich.com/2011/01/harmony-of-my-dreams/#sharp_functions>
>>> ),
>>> but arrows express mutable function objects per
>>>
>>> http://wiki.ecmascript.org/**doku.php?id=strawman:arrow_**
>>> function_syntax<http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax>
>>>
>>> which is the current source of truthiness.
>>>
>>> I left a comment about this on the YUI blog, saw it post yesterday, but
>>> it's gone now. Cc'ing Doug.
>>>
>>
>> It seems I misunderstood what we were agreeing to. I think the (this...)
>> form is critically important, and the immutability thing as well.
>>
>
> We had an agreement last year in TC39 to avoid making new shorter function
> syntax implicitly freeze where the new shorter syntax falls in full
> function syntax's general body-plan. This was the impetus for the # prefix,
> which also can apply to object and array literals.
>
> We're not going to implicitly freeze arrows. It was never in the strawman,
> or on the whiteboard during the negotiations.
>
> I agree that leading |this| could be important for dynamic non-method
> use-cases, but those are relatively rare (let's not discount JQuery, but
> again, it could use long functions and survive). We could put
> leading-this-parameterization on the agenda for May, but we'll have to be
> careful not to lose consensus on arrows.
>
>
Exactly -- I do remember leading `this' of #-functions, and even talked
myself about it on one of the confs, but I was surprised to see it in
Doug's article on -> functions (now it's clear that it was in wiki as well,
but has been removed).

Notice though, that providing such a Pythonic manual leading `this' just
makes the same manual "this-manipulations", but from the vice-versa side:
In case of normal functions you work implicitly with the dynamic `this',
but should manually capture it using `bind' or saving to a variable if
needed static `this'. In case of -> functions with the leading `this' you
do the same, but capture dynamic `this' -- still manually. Which seems the
same job to do.  I.e. two vice-versa in semantics, but still the same,
function types.

Probably dynamic `this' is really rare in this cases and nobody will use
leading `this', but when people will need it, perhaps it's good to provide
it. Otherwise, they will have to mix different types of functions by
different reasons. In one case a user uses arrow function for shortness, in
other case she should switch to "old-fashion" function expression, because
she says: "hey, I need dynamic `this', but those guys didn't give me such
ability". Lately, I believe users will work out some common patterns and
some of the function types will just die and desperate. The condition for
this -- a function should have all the possible ways of usage/compromises
(short syntax, ability of dynamic/static `this', frozen).

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120402/48322cb1/attachment.html>


More information about the es-discuss mailing list