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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
