No more modes?
Mark S. Miller
erights at google.com
Wed Oct 13 16:31:45 PDT 2010
Recently, I met with the Google V8 team for two full days. One message that
came through loud and clear, that I said I would relay to the list, is
"please, no more modes."
Since we almost never get to retire anything that old code depends on,
addition of modes (like "use strict") adds to implementation complexity.
They understand why we needed to introduce the "use strict" mode switch
specifically. But as we go forward, they'd really like to see ES-Harmony
avoid further mode switches. If we keep ES-Harmony practically upwards
compatible from ES5/strict, then on a browser supporting ES-Harmony, "use
strict" can be the way to opt in to harmony as well.
This has several implications.
* New harmony keywords should already be reserved in ES5/strict. Or at least
be so rare in actual code that their introduction does not create a
practical conflict. (This restriction need not apply to contextually
reserved words, provided that the context is one which would otherwise cause
a syntax error.) AFAICT, all the already-accepted harmony proposals (<
http://wiki.ecmascript.org/doku.php?id=harmony:proposals>) obey this
* Likewise, new properties or global variables should be unlikely to
conflict with those in existing code, though with feature testing this is a
softer constraint. After all, ES5 (barely) survived the introduction of the
new "JSON" global and (more easily) survived the introduction of the new
reflective APIs. Accepted harmony proposals would add globals "Proxy" and
"WeakMap" and the methods "Object.getPropertyDescriptor" and
"Object.getPropertyNames". My guess is that all these are adequately
* ES5/strict implementations as deployed in non-beta releases should obey <
If they don't, then either a separate opt-in will be necessary or we will
have to retreat from some of the accepted harmony proposals. For example, if
browsers deploy a harmony-incompatible semantics for "let", "const", and
nested named functions, and if ES5/strict code comes to depend on those
non-standard extensions, then without an additional opt-in it becomes
impossible to deploy harmony without breaking that code.
Going through the active strawmen, most are not particularly problematic on
these grounds. Although <
is presented as if using a "constructor" keyword, if it goes forward I think
we all expect it would actually use "class" instead. However, the module
proposal currently uses "module" as a keyword, which is not reserved and is
probably in active use. Could we use (the already reserved) "package"
instead? And the module proposal would have harmony scripts as well as
harmony modules be evaluated in a scope without the global object at the
bottom of the scope chain. While I hate global scope and would welcome this
cleanup, I don't see how to migrate script code to that discipline without
an additional opt-in. (And indeed, the current modules proposals does rely
on an additional opt-in to gate this change.)
 Making an ES5/strict error condition be a non-error in harmony is not
formally upwards compatible, since old code could depend on that error. In
the Caja design documents, we'd say that ES5/strict is a "fail stop subset"
of ES-Harmony. Looked at from the other direction, such fail-stop
supersetting is often practically upwards compatible, to be examined on a
case by case basis, especially when the error in question is a syntax
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss