Le 21/02/2013 19:16, Mark S. Miller a écrit :
On Thu, Feb 21, 2013 at 9:12 AM, David Bruant <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
