Opt-out schemes for ECMAScript 3.1
I was just looking at the proposed implementation of JSON (which
apparently is already implemented in IE 8 beta 2[1]).
This implementation actually differs pretty much from Douglas
Crockford's original reference implementation[2].
Prototype's JSON implementation was mapped on the original one (but
avoided extending Object.prototype for obvious reasons[3]) and method
names were changed (from toJSONString to toJSON) to avoid conflicting
with it should it become part of the standard...
I know it's most probably too late now to do anything about it, but
I'm surprised that this hasn't been taken into consideration when the
specs were designed.
Any suggestions on how we should handle this ? And how this should be
handled in the future so innovation isn't sniffled by the fear of
possible conflicts with a possibly upcoming native implementation ?
(FWIW, a good deal of what is making it's way into ES 3.1
On Nov 18, 2008, at 8:34 PM, William Edney wrote:
All -
In reviewing the proposed ECMAScript 3.1 specification, we have
identified what we feel is a grave situation for the ECMAScript
community and the Web at large: the omission of an explicit opt-in
mechanism for ECMAScript 3.1.
The last work on opt-in versioning was recorded here:
For ES3.1 we hope to extend existing objects with new properties not
used by common libraries, or else by codifying existing library
practice. More below in detail.
These issues have been debated elsewhere and a variety of counter- arguments have been put forth. However, in our view:
- It is insufficient to claim that 'these changes are minor'.
Agreed.
This is irrelevant since they overlay existing semantics, no matter
how 'minor' they are. They have the potential to break the Web, and
that's not 'minor'. For example, when 'foreach' is defined on
Array.prototype by a JS library, Mozilla engines implementing
JavaScript 1.6 hang.
I'm guessing you mean forEach -- but I am unable to reproduce. Can you
mail me a testcase or just file a bug? Thanks.
- It is insufficient to claim that 'object testing can be performed
to work around new features that are unwanted'. Again, this is not
relevant. Scripts in the field authored years ago by a long-gone
developer cannot be magically upgraded via time machine to do object
testing for features that are now being standardized or implemented
by a browser vendor or specification committee.
Agreed again. The hope is to match the de-facto standards where they
exist.
- It is insufficient to claim that 'if you define these properties,
they'll just overlay ones that we're defining for ES 3.1'. Many of
these same-named properties have different semantics that vary from
library to library.
Let's get to specifics to make progress here.
What about new ES 3.1 engine code that is calling this new
functionality and is now dealing with a JS-defined property that
behaves very differently?
ES3.1 generally avoids depending on overrides. This is a reality-based
(i.e., implementation-driven) correction to ES1-3, particularly for
use of standard constructors and prototypes. See:
and the Kona draft's use of "standard built-in
constructor" (redundancies aside, as DSH noted in the "new Object()"
thread just posted today).
This is related to point #1. Many libraries out there add a 'bind'
property to Function.prototype, and at least the ones we know of
don't take a varargs list for their version of 'bind'.
Where would a bind override be used by ES3.1 pseudo-code or prose?
I'm skipping your point 4. I agree with it in general, but the
specifics matter.
ES3.1 has limited scope in which to dodge the opt-in versioning
bullet. Let's address its specific compatibility hazards in order to
avoid over-engineering versioning now for 3.1, instead of in Harmony
when we have more time to spec and trial-implement, and get it right.
- It is insufficient to claim that 'well, we've surveyed a lot of
code out there and so far haven't found any conflicts with what
we're proposing'. There's a lot of JavaScript that doesn't exist on
the Internet. It exists in non-public web sites by the truckload and
is not visible to us. This community is not omniscient around how
JavaScript is being used 'out in the wild'.
Absolutely agree, which is why TC39 has agreed to two interoperating
implementations available for testing before the specification is
finalized. Of course, this is not as good as shipping those to mega-
user cohorts and waiting years for complaints, but we can't afford to
do that -- we'll unwind and implementations will go their own ways, or
something worse will happen.
isCallable operator New operator checks for a call method and will return inconsistent
results across browsers (RegExp in some implementations will return
true but not in others since RegExp.prototype.call isn't part of the
standard).
There is no RegExp.prototype.call in Mozilla's implementations, but I
see your point. It has led us to revert typeof /hi/ to evaluate to
"object" in Firefox 3, and we're likely to get rid of callable regexps
soon too, as I've written here.
But this is not an ES3.1 issue. It's a Mozilla issue.
Conflicting framework implementation accepts any object and
returns true if the object is a) a Function instance, b) not marked
as a DNU.
(DNU = doesNotUnderstand for those not SmallTalk-aware.)
I don't see the conflict. IsCallable is an internal method in ES3.1.
It's not exposed to script and existing "callable" predicates should
do what they've always done. Any disagreement will not surprise old
code, since it won't use new forms that depend on the new internal
method. Again the callable regexp bug is Mozilla's, not Ecma's.
10.0 Executable Code and Execution Contexts: What is the characterization of code which is added to a program
dynamically by adding a <script>inline_code_here</script> tag? Is
that considered "eval code" or are the separate contents treated as
global, function, and eval code respectively?
This question has nothing to do with ES3.1 either. Since ES1, script
tag inline content and out-of-line src are both "global code".
As a related question, what is the strict lexical context of such
code? (currently it would appear to be the global context which
seems appropriate)
Lexical != dynamic, so strict is a property of each script, not a
sticky property of a global object.
10.1.1 Strict Mode Code Is the intent here that different <script> nodes would be able to
define different settings for strict vs. unrestricted?
Yes.
11.1.5 In the syntax discussion on PropertyAssignment the verbs "get" and
"set" are used. Are these going to be treated like keywords?
Reserved words? Something else? They will likely conflict heavily
with frameworks which already use get/set "bean-like" APIs for
encapsulating property access. As an aside, getters can take parameters too, at least in the
environments I've worked with in the past, so not supporting a
parameter list for getters might restrict their value in those more
complex cases.
This object initialiser syntax is all based on Mozilla's
implementations, cloned in 3 of 4 other top browsers. The get and set
identifiers are not new unconditionally-reserved words, they're
keywords in context. They are part of new (to ES3) syntax, which
cannot collide with existing library code built on prior syntax.
12.1 Block Scope Please clarify, it appears this will continue to work for existing
code due to how lexical contexts are mapped. Is that correct? In
other words, will the current functionally-scoped vars etc be
visible to the block? Presumably yes.
Yes, at last week's meeting we fixed strict mode to allow var in block
statements and other cases the Kona draft was trying to forbid. Look
for the obvious fixes (removals) in a new draft.
15.2.3.5 Object.create Conflicts with frameworks which have already implemented this
method as an alternative constructor to using raw "new X" calls for
object creation. In particular, create is overridden by subtypes and
performs differing operations depending on the type.
What frameworks? Is it really a method on Object?
Prototype has Class.create, but that does not conflict.
15.2.3.14 Object.keys Conflicts with frameworks which have already implemented keys
properties, particularly for custom Hash object types.
Prototype has an Object.keys. My position at Kona was that we should
standardize that: for-in order and no optional "fast" param. TC39
members in attendance agreed. Is there any other precedent here? If so
does it conflict with Prototype?
15.3.4.5 Function.prototype.bind Almost certain to conflict with all major AJAX frrameworks, since
they almost all implement a bind method whose signature and
semantics are somewhat different.
I'll defer getting into the details for now and argue that we are
trying to standardize a common bind that works like these precedents.
If they are not all compatible with some useful union or intersection,
we'll have to consider dropping back to perhaps less useful but common
intersection semantics, or (I hope not!) using another name.
For now we are going to try to unify and heal -- it looks doable, but
we'll find out before standardizing. Please cite known conflicts and
hard cases.
At the Kona meeting I pointed out that ES3.1's sharing of .prototype
between the |this| function and its partially applied form returned
by .bind (in order to support operator new) was incompatible with
existing libraries such as Prototype. We agreed to field-test this and
see what breaks. I've never seen a .bind result new'ed, but I welcome
evidence that this is done in ways that shared .prototype would break.
Yes, we are on the slippery slope, but I think we should take this
chance. A bind method is insanely common, yet tedious to reinvent or
acquire. The ones I've studied have a lot in common. The common cases
should be standardized. You're right that doing so might require opt-
in, but that's not for sure yet. We still have time to rename or add
opt-in or opt-out, as we learn more in the next few months.
15.3.5.4 Function.prototype.name This will conflict with at least one framework which currently
sets a name property on Function instances to store their name, and
which assigns 'anonymous' as the name when not found.
This refers to:
15.3.5.4 name
The value of the name property is the name of the function, or an
empty string if the function is anonymous. This property has the
attributes { [[Writable]]: false, [[Enumerable]]: true,
[[Configurable]]: false }.
I missed this, thanks for pointing it ou. It is incompatible.
SpiderMonkey has a name property of Function instances (note: not
Function.prototype.name), but it's read/write. This is a good catch.
I'll get the trac opened up next week and log this one.
15.4.3.2 Array.isArray Admittedly this is a "type method" rather than an instance method,
but the isArray function has historically returned true if the
argument was a Java array (due to LiveConnect) so this would change
the semantics depending on the context.
You're now arguing about what you would prefer for semantics of a new
ES3.1 method. You are not citing any evidence of a compatibility
problem hinging on the name Array.isArray.
On the semantic point, we need a way to test [[Class]] == "Array", in
the spec's own terms and for self-hosting things like
Array.prototype.concat. Anything catering to LiveConnect can be
layered on top by some other spec or implementation.
Date.now Collision
With what? We've shipped this static method for many years. I know of
no conflicting precedent.
This is another case of standardizing /de jure/ what has been de-facto
standardized by implementations.
*.prototype.toJSON Collision
IIRC, the precedent is crock's json2.js. Is there any conflict?
15.5.4.20 String.prototype.trim Collision
What specific precedent do you mean, and how does the 3.1 method differ?
Additional Array iterators.
15.4.4.15 Array.prototype.lastIndexOf 15.4.4.14 Array.prototype.indexOf Will conflict with frameworks already implementing this function.
The semantics do appear to be consistent with those of the
implementations I'm aware of though, so this probably won't cause
failures.
These have been in SpiderMonkey for years, and they were cloned along
with the map/filter/etc. methods by other engines (I believe -- check
my claim here, please).
15.12 JSON Conflicts with frameworks which have already implemented this
object.
See above about json2.js, which is pretty old.
Annex D Changes to RegExp.prototype will cause isRegExp() in at least one
framework to break since it relies on the fact that RegExp objects
currently return Object as a way of distinguishing them from
Function instances which also implement both apply and call in
certain browsers (thanks to prior releases of new functionality).
No, changing RegExp.prototype to have [[Class]] "RegExp" does not
affect typeof (what you must mean by "current return Object").
The Mozilla callable RegExp kerfuffle is our (Mozilla's) bug to fix.
This Annex D informative item is a change to match what all browsers
(or 3 of 4, I forget) do. ES3 tried to say that only RegExp.prototype
was an Object instance, while all other native prototypes (e.g.
Date.prototype) were first-born instances of their constructors. It's
de-facto => de-jure standardization again, a good thing.
If future versions continue to define properties with no explicit
opt-in / opt-out mechanisms in place, the consequences get more
serious with each passing year as JavaScript's popularity curve is
increasing, not decreasing. There may be an ES 3.2... who knows?
Not likely because the spec formalism must die. Harmony or bust.
For that reason we strongly urge the committee to consider using the
same opt-in approach for ES 3.1 that will be required for ES Harmony.
That's plausible, but in my experience, most users won't version- select carefully.
Failure to require an opt-in approach with the standard will break
existing scripts.
We'll find out, but we aim to codify existing practice. This is easier
in Python or Perl with explicit deprecation/obsolescence machinery and
big-stick implementation leverage (only one C-Python, people want to
use its new features). It's hard on the web, but still doable. The ES2
and ES3 standards codified existing practice too.
Try looking at it the other way 'round: developers hate MIME types and
forget to use them even if they believe they ought to. It's likely
that 3.1 code will leak into default version space. We will test-
implement as we finish the 3.1 spec and try to find breaking changes.
If we can't fix them (somehow), we'll have to rename or remove them.
Our proposed opt-out approach would take the following form:
An addendum to the specification whereby ES engine vendors agree to
use a host-language mechanism that will cause their engines to shift
into 'ES 3.0 only' mode, ignoring all of the new properties and
features of ES 3.1.
We have some code to do this in SpiderMonkey. This kind of "opt-
in" (it's not really opt-out -- nothing "opts" by defaulting to the
unspecified version) is necessary for reserved identifiers, even
though they are contextually reserved only (see proposals:reserved_words)
.
It's possible we'll have to extend this version selection machinery to
handle JSON, but I doubt we will. IE8 is shipping ES3.1 JSON already,
and this smoked out a facebook .js file that conflicted with json2.js
and ES3.1. I believe it has been fixed (I'd like to confirm that
kill ;-).
Anyway, your thinking here is good but we are not ready to foist this
versioning complexity on the ES3.1 spec, which bulks up the tired old
spec-formalism bones of ES1-3.
Here is an example of what we would propose:
<script type="application/javascript;version=1.5">...</script>
A second form (for those in the pure ECMAScript world):
<script type="application/ecmascript;version=3.0">...</script>
See RFC 4329 (www.ietf.org/rfc/rfc4329.txt). This is covered to
some extend by
but not incorporated into ES3.1.
Note that this has the distinct advantage of being able to be used
by markup developers with no ECMAScript development experience who
can 'tweak their script tag to make their scripts run again'.
Or not -- Larry Masinter points to MIME type botches common on the web
and in server config files. He's right; XML namespace URIs are as bad
or worse. Good thing the client dictates inline and src script type
and we don't have to worry about server configs!
But you are still creating a huge fat-finger hazard here, in expecting
much developer opt-in for what should be a codify-existing-practice ".
1" upgrade to ES3.
I'll stop here, because I continue to believe that we can codify
existing practice in standardizing ECMAScript. I'm also skeptical of
opt-in versioning's usability. It therefore seems to me more helpful
at this juncture to study details about known and potential problems
(conflicts among existing libraries for common names newly specified
in ES3.1), than to jump with both feet to a 3.1 versioning solution.
All -
In reviewing the proposed ECMAScript 3.1 specification, we have
identified what we feel is a grave situation for the ECMAScript
community and the Web at large: the omission of an explicit opt-in
mechanism for ECMAScript 3.1.
In the nine years since ECMAScript 3.0 was finalized, the amount of
code written against the ES 3.0 standard has grown by leaps and
bounds. There are literally millions of lines of code written against
this standard.
In the course of writing so much script, developers of both frameworks
and individual applications invariably chose property names, global
variable names, etc. that are now colliding with those chosen for the
ES 3.1 specification.
These decisions were made by well-intentioned developers who were all
under the impression, from looking at drafts of the JavaScript 2.0 /
ES edition 4 specifications all the way back to 1999, that the next
version of ECMAScript would have some sort of 'explicit opt-in'
versioning mechanism.
Since the momentous August 2008 decision to split the upcoming work
into ES 3.1 and ES Harmony initiatives, work has progressed on the ES
3.1 specification, but with no mention of the ability to explicitly
opt-in or opt-out of this version of the language.
In his August 2008 posting announcing the split, Brendan had this to
say:
"... Both the appropriateness of new syntax, and the need to make
incompatible (with ES3 extensions) semantic changes, motivate opt-in
versioning of harmonized successor edition. ..."
so we know that 'explicit opt-in' is coming for Harmony. That's great,
but what about ES 3.1? There are property additions, global namespace
additions, etc. that make it incompatible with same-named developer
extensions.
We've worked directly over the years with numerous small web firms
which have extensive HTML/CSS skill but limited JS expertise. It is
important for the authors of this specification to understand that
there are millions of lines of JavaScript that are in production use
in an environment where:
There is no expertise to change / upgrade the code.
There may be an available HTML developer who can tweak an HTML tag
to specify a version number to 'make that script work again'.
Upgrades to the browser are dependent on scripts continuing to work
with little or no maintenance. If incompatible changes to JavaScript
are made 'silently', and scripts stop working, browsers stop getting
upgraded. This is definitely not in the best interest of the Web as
a whole.
These issues have been debated elsewhere and a variety of counter- arguments have been put forth. However, in our view:
It is insufficient to claim that 'these changes are minor'. This is
irrelevant since they overlay existing semantics, no matter how
'minor' they are. They have the potential to break the Web, and that's
not 'minor'. For example, when 'foreach' is defined on Array.prototype
by a JS library, Mozilla engines implementing JavaScript 1.6 hang.
It is insufficient to claim that 'object testing can be performed
to work around new features that are unwanted'. Again, this is not
relevant. Scripts in the field authored years ago by a long-gone
developer cannot be magically upgraded via time machine to do object
testing for features that are now being standardized or implemented by
a browser vendor or specification committee.
It is insufficient to claim that 'if you define these properties,
they'll just overlay ones that we're defining for ES 3.1'. Many of
these same-named properties have different semantics that vary from
library to library. What about new ES 3.1 engine code that is calling
this new functionality and is now dealing with a JS-defined property
that behaves very differently? This is related to point #1. Many
libraries out there add a 'bind' property to Function.prototype, and
at least the ones we know of don't take a varargs list for their
version of 'bind'.
It's been said that 'since no one really complained when Brendan
added new functionality for JavaScript 1.6 - 1.8, no one must really
care all that much'. This is not a good rationale at all. Some of us
have already had to dodge these new additions in the Mozilla engine
and we personally know of one case where we were using a third party
library that defined an incompatible 'foreach' method on the Array
object that had to be renamed to avoid collision. Additionally, what
we're talking about now is wholesale additions and changes to a multi- vendor standard, not a few additions made by one vendor - and one who
was responsible enough (at least for JavaScript 1.7/1.8) to require
a version be specified in the <script> tag.
It is insufficient to claim that 'well, we've surveyed a lot of
code out there and so far haven't found any conflicts with what we're
proposing'. There's a lot of JavaScript that doesn't exist on the
Internet. It exists in non-public web sites by the truckload and is
not visible to us. This community is not omniscient around how
JavaScript is being used 'out in the wild'.
In particular, we know of a large JavaScript framework in continuous
use with over 300K lines of JavaScript. Here is a survey we made of
that the specification with to that library (or general
comments with to language usage):
isCallable operator New operator checks for a call method and will return inconsistent
results across browsers (RegExp in some implementations will return
true but not in others since RegExp.prototype.call isn't part of the
standard). Conflicting framework implementation accepts any object and
returns true if the object is a) a Function instance, b) not marked as
a DNU.
10.0 Executable Code and Execution Contexts: What is the characterization of code which is added to a program
dynamically by adding a <script>inline_code_here</script> tag? Is that
considered "eval code" or are the separate contents treated as global,
function, and eval code respectively? As a related question, what is the strict lexical context of such
code? (currently it would appear to be the global context which seems
appropriate)
10.1.1 Strict Mode Code Is the intent here that different <script> nodes would be able to
define different settings for strict vs. unrestricted?
11.1.5 In the syntax discussion on PropertyAssignment the verbs "get" and
"set" are used. Are these going to be treated like keywords? Reserved
words? Something else? They will likely conflict heavily with
frameworks which already use get/set "bean-like" APIs for
encapsulating property access. As an aside, getters can take parameters too, at least in the
environments I've worked with in the past, so not supporting a
parameter list for getters might restrict their value in those more
complex cases.
12.1 Block Scope Please clarify, it appears this will continue to work for existing
code due to how lexical contexts are mapped. Is that correct? In other
words, will the current functionally-scoped vars etc be visible to the
block? Presumably yes.
15.2.3.5 Object.create Conflicts with frameworks which have already implemented this
method as an alternative constructor to using raw "new X" calls for
object creation. In particular, create is overridden by subtypes and
performs differing operations depending on the type.
15.2.3.14 Object.keys Conflicts with frameworks which have already implemented keys
properties, particularly for custom Hash object types.
15.3.4.5 Function.prototype.bind Almost certain to conflict with all major AJAX frrameworks, since
they almost all implement a bind method whose signature and semantics
are somewhat different.
15.3.5.4 Function.prototype.name This will conflict with at least one framework which currently
sets a name property on Function instances to store their name, and
which assigns 'anonymous' as the name when not found.
15.4.3.2 Array.isArray Admittedly this is a "type method" rather than an instance method,
but the isArray function has historically returned true if the
argument was a Java array (due to LiveConnect) so this would change
the semantics depending on the context.
Date.now Collision
*.prototype.toJSON Collision
15.5.4.20 String.prototype.trim Collision
Additional Array iterators.
15.4.4.15 Array.prototype.lastIndexOf 15.4.4.14 Array.prototype.indexOf Will conflict with frameworks already implementing this function.
The semantics do appear to be consistent with those of the
implementations I'm aware of though, so this probably won't cause
failures.
15.12 JSON Conflicts with frameworks which have already implemented this
object.
Annex D Changes to RegExp.prototype will cause isRegExp() in at least one
framework to break since it relies on the fact that RegExp objects
currently return Object as a way of distinguishing them from Function
instances which also implement both apply and call in certain browsers
(thanks to prior releases of new functionality).
If future versions continue to define properties with no explicit opt- in / opt-out mechanisms in place, the consequences get more serious
with each passing year as JavaScript's popularity curve is increasing,
not decreasing. There may be an ES 3.2... who knows?
For that reason we strongly urge the committee to consider using the
same opt-in approach for ES 3.1 that will be required for ES Harmony.
Failure to require an opt-in approach with the standard will break
existing scripts.
Should that be unacceptable for some reason we would urge adoption of
an opt-out approach. While this approach won't keep existing scripts
from breaking it would at least provide those without access to ES
expertise to make minor changes to their script tags to restore their
applications to a functional state.
Our proposed opt-out approach would take the following form:
An addendum to the specification whereby ES engine vendors agree to
use a host-language mechanism that will cause their engines to shift
into 'ES 3.0 only' mode, ignoring all of the new properties and
features of ES 3.1.
For HTML/SVG hosted applications of ECMAScript, this 'ES 3.0 only
mode' mechanism could take the form of a 'version' identifier placed
behind the MIME type in the <script> tag, as implemented by Mozilla
for JavaScript 1.7 & 1.8:
Here is an example of what we would propose:
<script type="application/javascript;version=1.5">...</script>
A second form (for those in the pure ECMAScript world):
<script type="application/ecmascript;version=3.0">...</script>
Note that this has the distinct advantage of being able to be used by
markup developers with no ECMAScript development experience who can
'tweak their script tag to make their scripts run again'.
For those of us kicking around the JS world for a while, this smacks a
bit of the old, de-facto, but never standardized:
<script language="JavaScript1.5">...</script>
Unfortunately, the 'strict backwards compatibility' feature of this
version identifier doesn't seem to be honored or is inconsistently
applied within various browsers:
language="JavaScript1.5"> syntax is used, 'Array.prototype.indexOf ===
undefined' returns false. Array's 'indexOf' was introduced in
JavaScript 1.6.
Ditto for Safari 3.1.2.
IE7 doesn't respond to this directive. It only works with version- specific values up to "JavaScript1.3". This is very confusing as
JScript 5.5 and above is supposed to be JavaScript 1.5 compliant
(although we all know there's still work to be done here).
Additionally, the 'language' attribute was never really standardized
and so is probably a poor choice for this capability. The Mozilla crew
seems comfortable with using a 'version=' after the MIME type, so
that's fine. The point is strict adherence to the defined version,
unlike the loose interpretation we see with the 'language' attribute.
As with the older 'language="..."' attribute, if the value of the
'type' attribute is just 'application/javascript' (or 'application/ ecmascript'), then the latest version of JavaScript will be used.
Therefore, we would like these statements to be confirmed, discussed,
debated by the committee:
ES Harmony will have an explicit opt-in mechanism, either through
the 'language' it is being hosted in (HTML, SVG, etc.) or via a
statement in the language itself.
The latest version of ECMAScript will be available in the current
execution environment if the following script tag syntax is used:
<script type="application/javascript">....</script>
When a version is explicitly given the engine will respect the
boundaries of that version, restricting the language to only those
features/properties standardized in the given version. Version numbers
and their related standards are:
JavaScript 1.5:
<script type="application/javascript;version=1.5">...</script>
OR
<script type="application/ecmascript;version=3.0">...</script>
JavaScript 1.6 (currently Mozilla-only):
<script type="application/javascript;version=1.6">...</script>
JavaScript 1.7 (currently Mozilla-only):
<script type="application/javascript;version=1.7">...</script>
JavaScript 1.8 (currently Mozilla-only):
<script type="application/javascript;version=1.8">...</script>
JavaScript 1.9:
<script type="application/javascript;version=1.9">...</script>
OR
<script type="application/ecmascript;version=3.1">...</script>
So, for those of you on the committee, 'ES 3.0 only mode' means
exclusion of all of that "red stuff" we see when we download versions
of the 3.1 specification :-). No additions to any objects, no new
global functions, no 'cautious' mode, no new semantics of any kind. It
is the language as it was frozen in November 1999.
The Web is no longer in its nascent phase. JavaScript is the COBOL of
the Web (with all due apologies to Brendan for that statement ;-) ).
Real, live production systems with millions of lines of ES edition 3.0
compliant JavaScript are in use everywhere, especially in places where
you can't see them. ES edition 3.0 is it for the foreseeable future
for many of these folks, no matter how 'flawed' it may be.
Thanks for listening.
All - In reviewing the proposed ECMAScript 3.1 specification, we have identified what we feel is a grave situation for the ECMAScript community and the Web at large: the omission of an explicit opt-in mechanism for ECMAScript 3.1. In the nine years since ECMAScript 3.0 was finalized, the amount of code written against the ES 3.0 standard has grown by leaps and bounds. There are literally millions of lines of code written against this standard. In the course of writing so much script, developers of both frameworks and individual applications invariably chose property names, global variable names, etc. that are now colliding with those chosen for the ES 3.1 specification. These decisions were made by well-intentioned developers who were all under the impression, from looking at drafts of the JavaScript 2.0 / ES edition 4 specifications all the way back to 1999, that the next version of ECMAScript would have some sort of 'explicit opt-in' versioning mechanism. Since the momentous August 2008 decision to split the upcoming work into ES 3.1 and ES Harmony initiatives, work has progressed on the ES 3.1 specification, but with no mention of the ability to explicitly opt-in or opt-out of this version of the language. In his August 2008 posting announcing the split, Brendan had this to say: "... Both the appropriateness of new syntax, and the need to make incompatible (with ES3 extensions) semantic changes, motivate opt-in versioning of harmonized successor edition. ..." so we know that 'explicit opt-in' is coming for Harmony. That's great, but what about ES 3.1? There are property additions, global namespace additions, etc. that make it incompatible with same-named developer extensions. We've worked directly over the years with numerous small web firms which have extensive HTML/CSS skill but limited JS expertise. It is important for the authors of this specification to understand that there are millions of lines of JavaScript that are in *production use* in an environment where: - There is no expertise to change / upgrade the code. - There may be an available HTML developer who can tweak an HTML tag to specify a version number to 'make that script work again'. - Upgrades to the browser are dependent on scripts continuing to work with little or no maintenance. If incompatible changes to JavaScript are made 'silently', and scripts stop working, browsers stop getting upgraded. This is *definitely* not in the best interest of the Web as a whole. These issues have been debated elsewhere and a variety of counter- arguments have been put forth. However, in our view: 1. It is insufficient to claim that 'these changes are minor'. This is irrelevant since they overlay existing semantics, no matter how 'minor' they are. They have the potential to break the Web, and that's not 'minor'. For example, when 'foreach' is defined on Array.prototype by a JS library, Mozilla engines implementing JavaScript 1.6 hang. 2. It is insufficient to claim that 'object testing can be performed to work around new features that are unwanted'. Again, this is not relevant. Scripts in the field authored years ago by a long-gone developer cannot be magically upgraded via time machine to do object testing for features that are now being standardized or implemented by a browser vendor or specification committee. 3. It is insufficient to claim that 'if you define these properties, they'll just overlay ones that we're defining for ES 3.1'. Many of these same-named properties have different semantics that vary from library to library. What about new ES 3.1 engine code that is calling this new functionality and is now dealing with a JS-defined property that behaves very differently? This is related to point #1. Many libraries out there add a 'bind' property to Function.prototype, and at least the ones we know of don't take a varargs list for their version of 'bind'. 4. It's been said that 'since no one really complained when Brendan added new functionality for JavaScript 1.6 - 1.8, no one must really care all that much'. This is not a good rationale at all. Some of us have already had to dodge these new additions in the Mozilla engine and we personally know of one case where we were using a third party library that defined an incompatible 'foreach' method on the Array object that had to be renamed to avoid collision. Additionally, what we're talking about now is wholesale additions and changes to a multi- vendor standard, not a few additions made by one vendor - and one who was responsible enough (at least for JavaScript 1.7/1.8) to *require* a version be specified in the <script> tag. 5. It is insufficient to claim that 'well, we've surveyed a lot of code out there and so far haven't found any conflicts with what we're proposing'. There's a lot of JavaScript that doesn't exist on the Internet. It exists in non-public web sites by the truckload and is not visible to us. This community is not omniscient around how JavaScript is being used 'out in the wild'. In particular, we know of a large JavaScript framework in continuous use with over 300K lines of JavaScript. Here is a survey we made of that the specification with regards to that library (or general comments with regards to language usage): ------- isCallable operator New operator checks for a call method and will return inconsistent results across browsers (RegExp in some implementations will return true but not in others since RegExp.prototype.call isn't part of the standard). Conflicting framework implementation accepts any object and returns true if the object is a) a Function instance, b) not marked as a DNU. 10.0 Executable Code and Execution Contexts: What is the characterization of code which is added to a program dynamically by adding a <script>inline_code_here</script> tag? Is that considered "eval code" or are the separate contents treated as global, function, and eval code respectively? As a related question, what is the strict lexical context of such code? (currently it would appear to be the global context which seems appropriate) 10.1.1 Strict Mode Code Is the intent here that different <script> nodes would be able to define different settings for strict vs. unrestricted? 11.1.5 In the syntax discussion on PropertyAssignment the verbs "get" and "set" are used. Are these going to be treated like keywords? Reserved words? Something else? They will likely conflict heavily with frameworks which already use get/set "bean-like" APIs for encapsulating property access. As an aside, getters can take parameters too, at least in the environments I've worked with in the past, so not supporting a parameter list for getters might restrict their value in those more complex cases. 12.1 Block Scope Please clarify, it appears this will continue to work for existing code due to how lexical contexts are mapped. Is that correct? In other words, will the current functionally-scoped vars etc be visible to the block? Presumably yes. 15.2.3.5 Object.create Conflicts with frameworks which have already implemented this method as an alternative constructor to using raw "new X" calls for object creation. In particular, create is overridden by subtypes and performs differing operations depending on the type. 15.2.3.14 Object.keys Conflicts with frameworks which have already implemented keys properties, particularly for custom Hash object types. 15.3.4.5 Function.prototype.bind Almost certain to conflict with all major AJAX frrameworks, since they almost all implement a bind method whose signature and semantics are somewhat different. 15.3.5.4 Function.prototype.name This will conflict with at least one framework which currently sets a name property on Function instances to store their name, and which assigns 'anonymous' as the name when not found. 15.4.3.2 Array.isArray Admittedly this is a "type method" rather than an instance method, but the isArray function has historically returned true if the argument was a Java array (due to LiveConnect) so this would change the semantics depending on the context. Date.now Collision *.prototype.toJSON Collision 15.5.4.20 String.prototype.trim Collision Additional Array iterators. 15.4.4.15 Array.prototype.lastIndexOf 15.4.4.14 Array.prototype.indexOf Will conflict with frameworks already implementing this function. The semantics do appear to be consistent with those of the implementations I'm aware of though, so this probably won't cause failures. 15.12 JSON Conflicts with frameworks which have already implemented this object. Annex D Changes to RegExp.prototype will cause isRegExp() in at least one framework to break since it relies on the fact that RegExp objects currently return Object as a way of distinguishing them from Function instances which also implement both apply and call in certain browsers (thanks to prior releases of new functionality). ------- If future versions continue to define properties with no explicit opt- in / opt-out mechanisms in place, the consequences get more serious with each passing year as JavaScript's popularity curve is increasing, not decreasing. There may be an ES 3.2... who knows? For that reason we strongly urge the committee to consider using the same opt-in approach for ES 3.1 that will be required for ES Harmony. Failure to require an opt-in approach with the standard _will_ break existing scripts. Should that be unacceptable for some reason we would urge adoption of an opt-out approach. While this approach won't keep existing scripts from breaking it would at least provide those without access to ES expertise to make minor changes to their script tags to restore their applications to a functional state. Our proposed opt-out approach would take the following form: An addendum to the specification whereby ES engine vendors agree to use a host-language mechanism that will cause their engines to shift into 'ES 3.0 only' mode, ignoring all of the new properties and features of ES 3.1. For HTML/SVG hosted applications of ECMAScript, this 'ES 3.0 *only* mode' mechanism could take the form of a 'version' identifier placed behind the MIME type in the <script> tag, as implemented by Mozilla for JavaScript 1.7 & 1.8: Here is an example of what we would propose: <script type="application/javascript;version=1.5">...</script> A second form (for those in the pure ECMAScript world): <script type="application/ecmascript;version=3.0">...</script> Note that this has the distinct advantage of being able to be used by markup developers with no ECMAScript development experience who can 'tweak their script tag to make their scripts run again'. For those of us kicking around the JS world for a while, this smacks a bit of the old, de-facto, but never standardized: <script language="JavaScript1.5">...</script> Unfortunately, the 'strict backwards compatibility' feature of this version identifier doesn't seem to be honored or is inconsistently applied within various browsers: 1. In Mozilla 1.9 / Firefox 3.0.4, even though the <script language="JavaScript1.5"> syntax is used, 'Array.prototype.indexOf === undefined' returns false. Array's 'indexOf' was introduced in JavaScript 1.6. 2. Ditto for Safari 3.1.2. 3. IE7 doesn't respond to this directive. It only works with version- specific values up to "JavaScript1.3". This is very confusing as JScript 5.5 and above is supposed to be JavaScript 1.5 compliant (although we all know there's still work to be done here). Additionally, the 'language' attribute was never really standardized and so is probably a poor choice for this capability. The Mozilla crew seems comfortable with using a 'version=' after the MIME type, so that's fine. The point is strict adherence to the defined version, unlike the loose interpretation we see with the 'language' attribute. As with the older 'language="..."' attribute, if the value of the 'type' attribute is just 'application/javascript' (or 'application/ ecmascript'), then the latest version of JavaScript will be used. Therefore, we would like these statements to be confirmed, discussed, debated by the committee: 1. ES Harmony will have an explicit opt-in mechanism, either through the 'language' it is being hosted in (HTML, SVG, etc.) or via a statement in the language itself. 2. The latest version of ECMAScript will be available in the current execution environment if the following script tag syntax is used: <script type="application/javascript">....</script> 3. When a version is explicitly given the engine will respect the boundaries of that version, restricting the language to only those features/properties standardized in the given version. Version numbers and their related standards are: JavaScript 1.5: <script type="application/javascript;version=1.5">...</script> OR <script type="application/ecmascript;version=3.0">...</script> JavaScript 1.6 (currently Mozilla-only): <script type="application/javascript;version=1.6">...</script> JavaScript 1.7 (currently Mozilla-only): <script type="application/javascript;version=1.7">...</script> JavaScript 1.8 (currently Mozilla-only): <script type="application/javascript;version=1.8">...</script> JavaScript 1.9: <script type="application/javascript;version=1.9">...</script> OR <script type="application/ecmascript;version=3.1">...</script> So, for those of you on the committee, 'ES 3.0 *only* mode' means exclusion of all of that "red stuff" we see when we download versions of the 3.1 specification :-). No additions to any objects, no new global functions, no 'cautious' mode, no new semantics of any kind. It is the language as it was frozen in November 1999. The Web is no longer in its nascent phase. JavaScript is the COBOL of the Web (with all due apologies to Brendan for *that* statement ;-) ). Real, live production systems with millions of lines of ES edition 3.0 compliant JavaScript are in use everywhere, especially in places where you can't see them. ES edition 3.0 is it for the foreseeable future for many of these folks, no matter how 'flawed' it may be. Thanks for listening. - Bill Edney & Scott Shattuck