On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg <rossb...@google.com>wrote:
> Mark's reformulation of the proposal is somewhat different from how I
> initially interpreted it -- in particular, wrt tying (merging)
> extended mode to strict mode. But it seems like the logical
> conclusion.
>
> The main problem with the proposal (in both Dave's original form and
> with Mark's refinement) is that it essentially gives up the idea that
> Harmony builds on strict mode. It is not at all obvious to me what
> implications that will have. A few observations:
>
> - 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.
>
> - Providing Harmony features in classic mode decreases the incentive
> for users to upgrade to strict mode. Is that a good thing?
>
Here's an interesting compromise I consider perfectly reasonable. We don't
*mandate* any ES6 code features be available in ES6 non-strict mode. But we
don't prohibit them either. For any ES6 features that have no dependence on
mode, like destructuring, we mandate that they be present in strict code,
and we make them normative optional (the new Appendix B category) in
non-strict code. Implementors are free to implement them or not in
non-strict mode, but if they implement them, it must mean the same thing as
the mandated meaning in strict code.
>
> - After Dave's posting I foresaw people wanting implicit opt-in with
> other constructs, e.g. classes or uses of `import' -- and voila, we're
> already there. But even with that, you still have to rely on explicit
> opt-in (via "use strict"?) for enabling some features elsewhere. As a
> result, we expect programmers to remember two separate, fairly random
> (for anybody not intimate with the history) lists of features that (1)
> require opt-in, and (2) imply opt-in. Style guides will probably
> suggest to put "use strict" on top of every Harmony program to escape
> the mess.
>
Every sane style guide will do so. And every linting tool should by default
warn on the presence of any non-strict code. And every IDE should offer to
make the code strict if it isn't already.
>
> - All this together (new features in old mode, implicit opt-in,
> explicit opt-in) makes it more subtle to see what piece of ES6 code is
> strict and which isn't. This is a disadvantage when reading code and a
> potential pitfall for refactoring (probably much worse than strict
> mode today).
>
The only sensible refactoring of non-strict code is to make it strict. All
other refactorings should start with that one.
>
> - Finally, not having a new mode restricts our ability to clean up the
> language beyond what's already in strict mode (see typeof).
>
> Considering all that, I can't help feeling that having a separate mode
> is cleaner, simpler, and easier to use. I think it also has more
> potential for providing a robust foundation for future evolution of
> the language.
>
> /Andreas
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
