A few arrow function specification issues

Taka Kojima taka at gigafied.com
Sat Apr 21 13:11:21 PDT 2012


I am in agreement with Angus on this one.

If there is no skinny arrow, hard |this| binding should not be part of the
spec. Fat arrow functions should default to lexical |this|, but if there is
no skinny arrow, it should not be a hard binding and call/apply should be
allowed, as well as bind,


On Sat, Apr 21, 2012 at 1:02 PM, Angus Croll <anguscroll at gmail.com> wrote:

> >>4) Should it be a dynamic error to try to use apply/call to set the this
> binding of an arrow function.
>
> >>Cons
> >>To much existing code speculatively binding the this value when invoking
> a function.
>
> >>I propose that call/apply simply ignore the this value when invoked on
> an arrow function.
>
> What is the pro of ignoring explicit |this| binding instructions in
> call/apply on arrow functions?
> What is the con of continuing to allow legacy code to speculatively bind
> the |this| value when invoking any function?
> Why is it so important that fat arrows do a hard |this| binding?
>
>
>
> On Fri, Apr 20, 2012 at 4:22 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>
>> Here are a few design alternates that have come up as I work the
>> specification draft for arrow functions
>>
>> 1) Always strict? Should all arrow functions be considered strict
>> functions?
>>
>> Pros
>> It's a new syntactic form, so it is it easy to make it be an implicit
>> opt-in to strict mode.
>> We generally want to encourage use of strict mode.
>> If not, there would no way to to make an expression-bodied arrow function
>> a strict function (other than by nesting it in strict code)
>> Always strict eliminates the need for some of the arrow special case
>> alternatives discussed below
>>
>> Cons
>> We shouldn't be trying to force use of strict mode.
>> Programmers who don't know about strict mode may get confused by the
>> application of strict mode  semantics to arrow functions
>> It would create a refactoring hazard for non-strict code.
>>
>> 2) Redeclaring eval in non-strict arrow functions
>>
>> Should strict mode eval declaration/assignment restrictions be be imposed
>> upon non-strict arrow functions?
>>
>> I propose disallow binding eval or assigning to it all arrow functions
>>
>> 3) Declaring arguments as a formal parameter, or local binding in a
>> non-strict arrow function
>>
>> The wiki proposal says arguments can't be used as an expression primary
>> but doesn't say anything about declarations
>>
>> I propose binding or assigning or referencing arguments within a arrow
>> function.
>>
>> 4) Should it be a dynamic error to try to use apply/call to set the this
>> binding of an arrow function.
>>
>> Cons
>> To much existing code speculatively binding the this value when invoking
>> a function.
>>
>> I propose that call/apply simply ignore the this value when invoked on an
>> arrow function.
>>
>> 5)  Should arrow functions define the [[HasInstance]] internal method.
>> In other words should should:
>>    obj instanceof () => {}
>> do?
>> If it doesn't have [[HasInstance]] then instanceof would throw a type
>> error.  Alternatively, it could have a [[HasInstance]] that always returns
>> false.
>> We have already decided that arrow functions don't have a [[Construct]]
>> internal method nor a prototype property.
>>
>> I propose that arrow functions do not have a  [[HasInstance]] internal
>> method.
>>
>> 6) Do arrow functions need to have per instance "caller" and "arguments"
>> poison pill properties?
>>
>> I propose no, because they are a new feature. But we can include a NOTE
>> warning against providing their non-standard legacy implementation.
>>
>> 7)All of the above questions also apply to functions defined using
>> concise method syntax in object literals or classes.  Should the same
>> answers apply to them?
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120421/0cc22ce5/attachment.html>


More information about the es-discuss mailing list