Transitioning to strict mode
bruant.d at gmail.com
Fri Feb 22 01:44:27 PST 2013
Le 21/02/2013 19:16, Mark S. Miller a écrit :
> On Thu, Feb 21, 2013 at 9:12 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
> Le 18/02/2013 23:29, Claus Reinke a écrit :
> What I'd like to understand is why likely static scoping problems
> should lead to a runtime error, forcing the dependence on testing.
> If they'd lead to compile time errors (for strict code),
> there'd be no chance of missing them on the developer engine,
> independent of incomplete test suite or ancient customer
> engines. Wouldn't that remove one of the concerns against
> using strict mode? What am I missing?
> I guess it's too late now for ES5 strict mode.
> What was the rationale behind making it a runtime error?
> I think there were plans to make it a compile-time error... was it
> with the ES6 opt-in? :-s
> Can it be retrofit in new syntax which are their own opt-in
> (module, class...)?
> For the ES5 semantics of the interaction of the global scope and the
> global object, how could you make this a static error?
"use hypothetic strict";
a = 12; // a was declared, no problem
b = b+1; // SyntaxError on the assignment regardless of |'b' in this|
If someone wants to assign to the global 'b', it's still possible to do:
this.b = b+1; // or
window.b = b+1;
Or maybe they forgot to declare b and they just need to declare it
somewhere to fix the SyntaxError. At least, the intent will be very
> What would you statically test?
"is the variable being assigned declared in the same script?"
And I am specifically speaking about variables assignments, that is
AssignmentExpression (ES5-11.13) where LeftHandSideExpression is an
If LeftHandSideExpression is a "MemberExpression [ Expression ]" or
"MemberExpression . IdentifierName" in which "MemberExpression" resolves
to the global object, I have no problem with it. At least it's very
explicit that the global object is being assigned something.
> Would you statically reject the following program, where
> <someExpression> is itself just some valid expression computing a
> value (that might be the string "foo")? Note that "this" below is the
> global object, since it occurs at top level in a program.
> "use strict";
> this[<someExpression>] = 8;
I would not reject it as I said above.
I think there are 2 different concerns:
1) assigning a value to an undeclared variable
2) adding a property to the global object
I think I only care about preventing the former (I'll talk about the
latter below), because the intent is ambiguous and the disambiguation
can be either "declare it" or "add a property to the global object like
you really mean it".
The rule for strict mode could have been: throw a SyntaxError when
trying to assign a value to an undeclared variable.
As I suggest in the guide, these errors are almost free to fix. Just add
"use strict";, read your console which tells you at which line there is
an error, what the syntax error is and fix it.
If people really want to add a property to the global object, they can
anyway through "this[<expression>] = 8" at the top-level scope as you
suggest or by aliasing the global in non-top-level scopes as in:
global[<expression>] = "value";
or using an existing alias like "window" or "frames" in the web browser.
So preventing people from adding global properties is a lost cause.
Preventing people from assigning to an undeclared variable isn't.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss