On Mon, Apr 2, 2012 at 12:47 PM, Brendan Eich <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
