Future proof "use strict";

[Michael Schurter-2]

I'm just a lowly Python/JS webdev eager to use ES5.  John Resig
encouraged me[1] to post this suggestion, so blame him if its no
good.  ;-)

For the record: my 2 original comments on "use strict" [2] [3]

Essentially my fear is that the meaning of "use strict" becomes
ambiguous when future versions of ECMAScript are released (6 and
beyond).

What seems reasonable for both ES users (webdevs) and implementors is
for ES engines to support only 2 modes: strict and permissible,
supporting fine-grained per-ES-version language support would cause
undue complexity for implementors.

However, when ES users enable the strict mode, they have a specific ES
version in mind (right now 5, but in the future perhaps 6, 5.1, etc).

Based on the 2 reasonable modes model I describe above "strict ES v5"
should be evaluated in the *permissible* mode by future ES versions.

Therefore, ES users need a way to define an ES *version* to target.
This could be as simple as:  "use strict 5"; which could even be used
alongside the current "use strict"; right now.

A more robust model might be to allow the mode to be defined in a
conditional statement:

if (ecmascript.version <= 5) "use strict";

As a side note, it would be nice if some sort of strictness stability
were to be guaranteed like API/ABI stability within major ES versions.
So that ES 5.1 strict == ES 5 strict != ES 6 strict.

Like I said, I could be way off base here.  I'm joining the discussion a
bit late and only from the perspective of an ES user.  :-)

Michael Schurter
schmichael on IRC, Twitter, etc

[1]
http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/#comment-385042
[2]
http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/#comment-384967
[3]
http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/#comment-385019


_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On May 22, 2009, at 2:54 PM, Michael Schurter wrote:

> Essentially my fear is that the meaning of "use strict" becomes
> ambiguous when future versions of ECMAScript are released (6 and
> beyond).

The Web doesn't rev just because a new edition of the standard comes  
out. If only we could use CPython's deprecating/obsolescence/from  
future import stuff. We can't, since old browsers persist for years  
and only go away unpredictably down the road.

So "use strict" has to mean in future years what it meant in the first  
year it appeared, absent explicit version selection.

You're right to note the possible version connection, but it is not  
mandatory. Users can say

"use strict";

in content targeting ES5 and downrev browsers, but need not opt into  
ES5 -- this is important for adoption. In other words, the above can  
and should appear in a <script type="application/javascript"> or even  
just <script> (no type attribute) tag. No RFC4329 ";version=..." MIME  
type parameter need be supplied, and current browsers don't all follow  
RFC4329 anyway.

With careful object detection and emulation (e.g., __lookupGetter__ as  
a fallback if Object.getOwnPropertyDescriptor is not detected), or  
just avoidance of new-in-ES5 features, the programmer nevertheless  
benefits from strict mode checking in the uprev browsers used for  
development and (some) testing.


> What seems reasonable for both ES users (webdevs) and implementors is
> for ES engines to support only 2 modes: strict and permissible,
> supporting fine-grained per-ES-version language support would cause
> undue complexity for implementors.

Yes, that's true.


> However, when ES users enable the strict mode, they have a specific ES
> version in mind (right now 5, but in the future perhaps 6, 5.1, etc).

If they do and the version changed strict mode -- which is possible,  
we've talked about strict mode becoming stricter over time -- then  
(and only then) will an explicit version selection pragma or MIME type  
parameter be required.

But as with Perl, we hope that simple, version-free "use strict" will  
suffice for a long time.


> Based on the 2 reasonable modes model I describe above "strict ES v5"
> should be evaluated in the *permissible* mode by future ES versions.

That's wildly optimistic. We have no idea when, if ever, a random  
string literal expressed as a useless statement might be safely  
interpreted to enable an incompatible mode of the language. It's  
unlikely any such code exists, but it is overtly incompatible.


> Therefore, ES users need a way to define an ES *version* to target.

Maybe, maybe not. We shouldn't assume this and over-couple "use  
strict" and a "use version".


> This could be as simple as:  "use strict 5"; which could even be used
> alongside the current "use strict"; right now.
>
> A more robust model might be to allow the mode to be defined in a
> conditional statement:
>
> if (ecmascript.version <= 5) "use strict";

The pragma is a compiler directive, a static property of code, and so  
must come first in a program or function body. It's not a runtime  
directive. You can't change to strict mid-parse, let alone at runtime.


> As a side note, it would be nice if some sort of strictness stability
> were to be guaranteed like API/ABI stability within major ES versions.
> So that ES 5.1 strict == ES 5 strict != ES 6 strict.

There won't be a 5.1 -- again we are not CPython, standards committees  
don't do minor or patch releases, and the Web moves slowly.

Definitely the notion of strictness should be stable. We don't know  
yet that we could make an ES6 "use strict" any stricter for existing  
content. It might be that doing so would, in that future year, "break  
(too much of) the Web". Even if there were explicit version selection  
(probably there will have to be for ES6, to hide new syntax from old  
user agents), if the migration tax is too high for a proposed  
"stricter" strict mode, it may not fly.

But for ES5 we are not getting into versioning. As noted previously,  
there are at least two aspects to versioning: <script> version,  
defaultable via an HTTP header (expressible with <meta http-
equiv=...>); and "frame version" for the shared object model in the  
whole window or frame that loads content including scripts.

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Michael Schurter-2]

On Fri, 2009-05-22 at 15:26 -0700, Brendan Eich wrote:

> On May 22, 2009, at 2:54 PM, Michael Schurter wrote:
>
> > Essentially my fear is that the meaning of "use strict" becomes
> > ambiguous when future versions of ECMAScript are released (6 and
> > beyond).
>
> The Web doesn't rev just because a new edition of the standard comes  
> out. If only we could use CPython's deprecating/obsolescence/from  
> future import stuff. We can't, since old browsers persist for years  
> and only go away unpredictably down the road.
>
> So "use strict" has to mean in future years what it meant in the first  
> year it appeared, absent explicit version selection.
>
> You're right to note the possible version connection, but it is not  
> mandatory. Users can say
>
> "use strict";
>
> in content targeting ES5 and downrev browsers, but need not opt into  
> ES5 -- this is important for adoption. In other words, the above can  
> and should appear in a <script type="application/javascript"> or even  
> just <script> (no type attribute) tag. No RFC4329 ";version=..." MIME  
> type parameter need be supplied, and current browsers don't all follow  
> RFC4329 anyway.
>
> With careful object detection and emulation (e.g., __lookupGetter__ as  
> a fallback if Object.getOwnPropertyDescriptor is not detected), or  
> just avoidance of new-in-ES5 features, the programmer nevertheless  
> benefits from strict mode checking in the uprev browsers used for  
> development and (some) testing.
>
>
> > What seems reasonable for both ES users (webdevs) and implementors is
> > for ES engines to support only 2 modes: strict and permissible,
> > supporting fine-grained per-ES-version language support would cause
> > undue complexity for implementors.
>
> Yes, that's true.
>
>
> > However, when ES users enable the strict mode, they have a specific ES
> > version in mind (right now 5, but in the future perhaps 6, 5.1, etc).
>
> If they do and the version changed strict mode -- which is possible,  
> we've talked about strict mode becoming stricter over time -- then  
> (and only then) will an explicit version selection pragma or MIME type  
> parameter be required.
>
> But as with Perl, we hope that simple, version-free "use strict" will  
> suffice for a long time.
>
>
> > Based on the 2 reasonable modes model I describe above "strict ES v5"
> > should be evaluated in the *permissible* mode by future ES versions.
>
> That's wildly optimistic. We have no idea when, if ever, a random  
> string literal expressed as a useless statement might be safely  
> interpreted to enable an incompatible mode of the language. It's  
> unlikely any such code exists, but it is overtly incompatible.
>
>
> > Therefore, ES users need a way to define an ES *version* to target.
>
> Maybe, maybe not. We shouldn't assume this and over-couple "use  
> strict" and a "use version".

The above makes sense.  Thanks for the thorough and patient
explanation.  :-)

> > This could be as simple as:  "use strict 5"; which could even be used
> > alongside the current "use strict"; right now.
> >
> > A more robust model might be to allow the mode to be defined in a
> > conditional statement:
> >
> > if (ecmascript.version <= 5) "use strict";
>
> The pragma is a compiler directive, a static property of code, and so  
> must come first in a program or function body. It's not a runtime  
> directive. You can't change to strict mid-parse, let alone at runtime.

Huh, I guess I assumed since you could change it depending on context
(eg within a function) as per John's post it was configurable at
runtime.  So you couldn't do:

(function() {
    var main = function() { /* do stuff here */ };
    var strict = function() {
        "use strict";
        main();                        // <-- A
        eval("("+main.toString+")()"); // <-- B
    };

    // Pretend ecmascript.version exists or a library to detect
    // the ES engine's capability is used.  :-)
    if (ecmascript.version <= 5)
        strict();
    else
        main();
})();

Is strict mode only enabled inside strict(), but never inside main()?

I'm guessing the code inside A is executed outside the strict context in
A, but I'm unsure of what B would do (scary code indeed).

> > As a side note, it would be nice if some sort of strictness stability
> > were to be guaranteed like API/ABI stability within major ES versions.
> > So that ES 5.1 strict == ES 5 strict != ES 6 strict.
>
> There won't be a 5.1 -- again we are not CPython, standards committees  
> don't do minor or patch releases, and the Web moves slowly.
>
> Definitely the notion of strictness should be stable. We don't know  
> yet that we could make an ES6 "use strict" any stricter for existing  
> content. It might be that doing so would, in that future year, "break  
> (too much of) the Web". Even if there were explicit version selection  
> (probably there will have to be for ES6, to hide new syntax from old  
> user agents), if the migration tax is too high for a proposed  
> "stricter" strict mode, it may not fly.
>
> But for ES5 we are not getting into versioning. As noted previously,  
> there are at least two aspects to versioning: <script> version,  
> defaultable via an HTTP header (expressible with <meta http-
> equiv=...>); and "frame version" for the shared object model in the  
> whole window or frame that loads content including scripts.
>
> /be

Once again thanks for the thorough and patient explanations.  I was
thinking under a number of wrong assumptions and just plain wrong.  :-)

Looking forward to using this feature!

-schmichael


_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss