Then, why not to put every feature on ES6 mode only and backporting them one
by one, giving time for each backport to see if it really works and not
putting effort to backport another one until the previous one is generally
accepted as safe?
Herby
-----Pôvodná správa-----
From: Allen Wirfs-Brock
Sent: Wednesday, January 04, 2012 6:08 PM
To: Andreas Rossberg
Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote:
...
- Despite the superficial "fewer modes" mantra, it actually doesn't
make the language simpler, but more complicated: instead of defining
the semantics for Harmony features only for strict-mode programs, we
now have to define many features for both modes (and mixed uses of
both modes). I.e., there are more syntactic and semantic combinations
to worry about.
Yes, I'm already seeing this as I look at the working draft of the ES6
specification to see how I would have to modify it to support this new
approach. Rather than working in a small number of discrete modes, each of
which implies a specific set of environmental semantic rules, I have to
consider pairwise interactions between features that span modes. Some
initial issues I've had to look at are include the possibility of the
presence of a local with scope when dealing with lexical declarations,
impacts of being able to redeclare 'eval' or 'arguments', and interactions
between formal parameter destructuring and non-strict mode arguments
objects.
If the impact was only on the spec. work this might not be a big deal, but
these sorts of mode-crossing feature interactions are also visible to
implementors and ES programmers and add practical and conceptual complexity
that they will have to deal with.
There certainly are features (for example, is and isnt) which seem to have
minimal impact in any mode. But for others, there are complexities that go
beyond just the syntactic compatibility issues. Modes (whether via explicit
or implicit opt-in) seem to help reduce this complexity.
I think Dave has pushed us down a useful path, but I also think we need to
carefully semantic interactions as well as syntactic compatibility issues
for each feature that we consider adding to "non-strict" code. In some
cases, it may make the language easier to understand and use if features are
only available in "strict mode".
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss