On Apr 23, 2012, at 10:15 AM, Andreas Rossberg wrote:
> On 21 April 2012 01:22, Allen Wirfs-Brock <[email protected]> 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.
>
> One more: It makes the rules for what mode applies where more
> complicated and less obvious.
Unsurprisingly, I agree.
> To be honest, that suggestion confirms one of my fears about "1JS" --
> ending up with a more complicated language with ad-hoc rules about
> which mode applies in which context. Please let's try to resist the
> temptation. As much as I would like to encourage strict mode, I think
> we should keep it orthogonal to other constructs as much as possible.
> I can bear tying it to modules, but let's not go any further.
>
>
>> 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
>
> Same here. If it's sloppy mode, let the sloppy mode rules apply as usual.
>
>
>> 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.
>
> I suppose the most natural semantics would be that, like 'this', '
> arguments' is bound lexically from a surrounding function, if present.
> But that's perhaps too confusing, so I'd be fine with ruling out its
> use completely.
We might be able to do soft binding without much ambiguity. I'll post something
here about it under separate cover.
>> 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.
>
> Yes, that is consistent with what happens today when you call/apply a
> function after 'bind'.
>
>
>> 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.
>
> Agreed. It would be weird to support HasInstance in the absence of the other.
>
>
>> 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.
>
> For simplicity and uniformity, I'd keep the same semantics as for
> ordinary functions. Don't special-case if there is no strong reason to
> do so.
>
>
>> 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?
>
> I'd prefer if concise method syntax stayed simple syntactic sugar for
> functions. Methods obviously need dynamic this. If you combine that
> with changes like the above, then you have implicitly introduced a
> third kind of function that cannot be described as (simple) syntactic
> sugar for any of the other two. That would be unfortunate, IMO.
>
> /Andreas
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
[email protected]
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
