I'm confused about the design constraints on ES4
brendan at mozilla.org
Sat Nov 10 21:10:39 PST 2007
On Nov 10, 2007, at 8:00 PM, Mark Miller wrote:
> * To prevent these new keywords breaking ES3 compatibility, these
> keywords are only recognized when a version attribute on the script
> tag says the script is in ES4.
This has happened before, FYI -- from ES1-3 under various vendor
experimental MIME types or script language attribute values -- and it
continued after ES3 with (at least) JS1.6 and 1.7 (application/
> * This attribute does create two languages in effect, but not two
> language implementations, and therefore does not violate the size
Writing "this attribute does create two languages in effect" seems to
conflate compatible successive versions with one a subset of the
other, and two completely separate programming languages. I'm not
sure what it means, so it's hard to tell what its significance is in
the bulleted list. I'm probably missing something obvious -- little
> * The intersection of ES3 and ES4 must be approximately as pleasant a
> programming language as ES3 currently is.
No, the intersection is "ES3 + reality" + two (known) true
incompatibilities. "ES3 + reality" means the ES3 spec was not
followed (for variously better and worse reasons) and the de-jure
standard needs to be adjusted based on what browsers actually do that
web developers actually count on.
"ES3 + reality" does not mean every last JScript bug, of course,
especially since many have not been emulated by other browsers'
implementations. It does not mean over-specifying what should remain
implementation-dependent (e.g., Date.parse as implemented in various
browsers). It does mean some case-by-case greater specification where
browsers differ in ways that hurt interoperation.
> If all this makes sense, does the following follow:
> * The ES4 language (as recognized with the version attribute) and the
> ES3 language must be able to smoothly share an implementation.
> * Whenever the goals of ES4 can be achieved by removing unneeded
> features from ES3 (e.g. "with"), rather than adding features, the
> implementation can smaller, and therefore even better for small
This does not follow if the goals of ES4 include backward
compatibility (they do), since the web depends all over the place on
"with". So the (common) implementation must support ES3 "with", and
adding runtime versioning to make "with" an error in ES4 just adds
code (a tiny amount for the version check) and makes migration harder
(more important that the miniscule version check overhead). See also
> Does this make sense so far? Am I missing something?
You wrote about design constraints, but also talked about goals of
ES4 without listing them. The two are not the same. Many design
constraints are imposed by backward compatibility with existing web
content. Goals such as optional static type checking and programming
in the large support on the other hand transcend compatibility
concerns by allowing migration away from old forms toward new ones.
There are no guarantees, but the best way to move the web is to
provide better forms and short (low-cost) migration paths to those
forms, in addition to deprecating the worse forms.
I expect "with" will be with us forever, BTW. My apologies to all!
If backward compatibility requires "with", and the new version does
not remove old forms even when you opt into it explicitly, then the
footprint is minimized. Since removing "with" is a non-starter given
the compatibility constraint, there's no gain in code size by adding
code to remove "with" when the new version is selected -- and there's
no gain in migration costs, since "with" costs are long-ago sunk and
not trivial to unsink. Bad sunk costs, i.e. bugs due to "with"
ambiguities, could be unearthed, but the existence of these
hypothetical bugs in quantity enough to offset the unsinking costs
need to be demonstrated.
Backward compatibility is not simple or static -- it is fuzzy and it
changes as the web changes. There's hope, but the time scales are
long and you can't force change by removing things from browsers. You
have to see competitors take the plunge, and even then you must face
down the rear guard (e.g., removing gopher from Firefox).
Hope this helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss