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.
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.
> 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
