Hi Brendan, I agree with most of your message, so only commenting on the
remainder.
On Wed, Jan 4, 2012 at 12:52 PM, Brendan Eich <bren...@mozilla.com> wrote:
[...]
> > - 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?
>
Lexical scoping (top level aside of course). Encapsulated functions. Sane
arguments. Poisoning of .caller, .callee, .arguments. Ability to write code
that continues to run on old browsers and to run sanely on old ES5
browsers. Throw errors on failed assignment rather than silently continuing
as if everything is fine. Throw exception on a failed delete. Throw on
assigning to an undefined variable rather than having misspelling silently
create a new global. Preventing an eval from corrupting its caller's
scope. Need I go on? Compared to ES5 strict, ES5 non-strict is insane.
Regarding adoption of strict, another audience we should keep in mind is
people newly learning JavaScript. Would you rather teach them to say "use
strict"; or teach them to program in a language without sane scope rules or
encapsulated functions, and with silent errors?
No -- "use strict"; the string literal expression-statement is meaningless
> pre-ES5, ES5-strict in ES5, and redundant in Harmony code.
I don't see how it can be redundant in harmony code. Say I write a script,
intending it to be harmony, but which doesn't begin with "class", "module",
"function*", or whatever else we decide is a new opt-in. But I want the
code above the first, say "module", to still obey harmony rules rather than
non-strict rules. I would still need to say something else at the top of
the script to ensure this.
>
> (BTW I still think we want a real |use strict;| pragma, to choke old
> implementations.)
Yes. Crock suggested this in the old ES5 days and I think it is still a
good idea:
"use strict"; // still runs on old browsers, but non-strictly
use strict; // causes an early error on old browsers.
Had we adopting it into ES5, it would have this meaning clearly. It may
still be a good idea, but consider the new complexity. Now the second form
also causes an early error on old ES5 browsers, where the script might
otherwise have been able to run strictly.
>
> Now what do you say?
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
