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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
