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/
javascript;version=1.7).
* This attribute does create two languages in effect, but not two
language implementations, and therefore does not violate the size
constraint.
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
help?
* 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.
Yes.
* Whenever the goals of ES4 can be achieved by removing unneeded
features from ES3 (e.g. "with"), rather than adding features, the
shared
implementation can smaller, and therefore even better for small
devices.
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
reformed with.
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,
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
