Transitioning to strict mode

[David Bruant]

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";
     var a;
     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 
explicit.

> 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 
Identifier.
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;
> console.log(foo);
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:
     (function(global){
         global[<expression>] = "value";
     })(this)
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.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130222/9c69ddd2/attachment-0001.html>