I'm confused about the design constraints on ES4

[Brendan Eich]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071110/f6d4636b/attachment-0002.html