Mark S. Miller wrote:
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich<[email protected]> wrote:
Who ever proposed that? It seems a misunderstanding. No one is saying that,
e.g., destructuring formal parameters, or a rest parameter, should flip the
containing function into strict mode. Banning duplicate formals in no wise
does that.
This is an example of the micro-modes issue. If optional, rest, and/or
destructuring needs to enforce no duplicates, then we have two
choices:
1) Make these features available only in strict code, which doesn't
require any new special case -- since strict already bans duplicate
parameter names.
Agree so far.
2) Make a micro-mode, adding yet additional mode switching in order to
supposedly avoid the complexity of dealing with one mode switch.
No, you are using micro-mode as an epithet without actually defining it
in a meaningfully different way from "new semantics for new syntax".
Are arrow functions, syntax and definite semantics, a "micro-mode"? If
not, why not? I suspect you are using a mental desugaring spec but
there's no such spec. Allen has to deal with whether arrows have
[[Construct]] (we decided no, because |this| is bound to outer |this|).
Is that a "micro-mode"? I say no.
By our previous criteria, #1 is obviously simpler than #2.
I dispute that. The complexity to count is user-facing, not
spec-internal or mental-desugaring or other invisible complexity. Users
need to know about arrows when writing them. When calling, not so much
(one cannot assume all functions are constructors, even in ES1 [builtins]).
Let's try to get to an apples-to-apples user-facing complexity metric,
and leave the stuff under the spec hood out.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
