There are multiple levels of opt-in versioning: (1) versioning of the language itself
(2) language support for versioning of libraries I agree with what you're saying wrt (1), but wrt (2), feature detection is feasible, and I'd think more tractable than version detection. Dave On Apr 17, 2010, at 9:38 AM, Brendan Eich wrote: > 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
