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, this is a trade-off. It probably helps developers migrate, provided they
choose sane combinations. For example, Allen (private correspondence) wondered
if a function using the arguments object is evolved to have destructuring
parameters:
function f({a,b}, c) { arguments[0] = {a:3,b:4}; return [a, b] }
f({a:1,b:2}, 3);
I say anyone wanting deep aliasing (f returns [3, 4]) should suffer
disappointment. I doubt developers want such deep aliasing, and no implementor
does.
We don't get to clean the slate with JS, so making "mode walls" between
language versions may help implementors (by which I include spec writers) but
that's about it. Authors are not helped, and mode walls probably hurt (we hear).
I think we're better off working through the combinations, removing legacy
(mis-)features as we go. For example, function f above, because it uses
destructuring parameters, opts into the new language which *is* based on
ES5-strict -- so there's no arguments aliasing at all!
The general idea would be that any new syntax that doesn't create backward
compatibility problems on its face opts the containing (or following, in the
case of new syntax in function head) body into strict mode. By body I probably
mean function or program body and not just braced block.
> - Providing Harmony features in classic mode decreases the incentive
> for users to upgrade to strict mode. Is that a good thing?
See above -- Harmony > ES5-strict in the proposal and so users do upgrade to
strict mode. They just don't have to sprinkle "use strict"; string literals
expression statements around. That's a win.
> - 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.
Which features?
> 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.
If the new syntax implies strict mode in the containing body, then this goes
away.
> - All this together (new features in old mode,
Nope. ;-)
> implicit opt-in,
Yup.
> explicit opt-in)
No -- "use strict"; the string literal expression-statement is meaningless
pre-ES5, ES5-strict in ES5, and redundant in Harmony code.
(BTW I still think we want a real |use strict;| pragma, to choke old
implementations.)
Now what do you say?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
