On Apr 16, 2010, at 2:31 PM, David Herman wrote:
PS Still, I have my doubts about using any such mechanisms for
versioning. Incidentally, ROC was just talking about versioning and
metadata on the web:
http://weblogs.mozillazine.org/roc/images/APIDesignForTheMasses.pdf
Rob's blog post:
http://weblogs.mozillazine.org/roc/archives/2010/04/api_design_for.html
He wasn't talking about JS API design, but some of the lessons still
apply.
Old WHATWG co-conspirators like me obviously agree on the principles
roc presents, but they do not work so well in JS compared to HTML or
even CSS. Consider HTML markup:
<video ...>
<object ...></object>
</video>
A new HTML5 video tag with an object tag as fallback, to use a plugin
to present the video for pre-HTML5 browsers. There are text-y examples
that work too, even if the degradation is not as graceful as you might
get with a plugin (plugins can lack grace too :-/).
CSS has standardized error correction from day one, although as noted
in comments on roc's blog it lacks "feature detection". But graceful
degradation seems to work as well with CSS as with HTML, if not better.
With JS, new syntax is going to make old browsers throw SyntaxErrors.
There's no SGML-ish container-tag/point-tag model on which to build
fallback handling. One could use big strings and eval, or XHR or
generated scripts to source different versions of the JS content --
but who wants to write multiple versions of JS content in the first
place.
The "find the closing brace" error correction idea founders on the
need to fully lex, which is (a) costly and (b) future-hostile.
Allowing new syntax in the main grammar only, not in the lexical
grammar, seems too restrictive even if we never extend the lexical
grammar -- we might fix important bugs or adjust the spec to match de-
facto lexical standards, as we did for IE's tolerance of the /[/]/
regexp literal.
So API object detection with fallback written in JS random logic works
(for some very practical if not theoretically pretty definitions of
"works") for the non-syntactic extensions coming in Harmony, assuming
we can dodge the name collision bullets. But for new Harmony syntax,
some kind of opt-in versioning seems required.
We survived this in the old days moving from JS1.0 to JS1.2 and then
ES3. One could argue that the web was smaller then (it was still damn
big), or that Microsoft's monopolizing helped consolidate around ES3
more quickly (it did -- IE started ignoring version suffixes on
<script language=> as I noted recently).
Roc's point about fast feedback from prototype implementations to
draft standards is the principle to uphold here, not "no versioning".
Obviously we could avoid new syntax in order to avoid opt-in
versioning, but this is a bad trade-off. JS is not done evolving,
syntax is user interface, JS needs new syntax to fix usability bugs.
I'm a broken record on this point.
Secondarily, new syntax can help implementations too, both for
correctness and optimizations.
So I should stop being a broken record here, and let others talk about
opt-in versioning. It seems inevitable. We have it already in a
backward-compatible but semantically meaningful (including runtime
semantic changes!) sense in ES5 with "use strict".
Opt-in versioning s not a free ride, but it is going to a destination
we need to reach: new syntax where appropriate and needed for
usability and productivity wins.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
