names [Was: Approach of new Object methods in ES5]
brendan at mozilla.com
Sat Apr 17 14:40:37 PDT 2010
On Apr 17, 2010, at 3:03 PM, David Herman wrote:
> 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
Yes, I agree.
TC39 has discussed a "frame" (meaning DOM window, ideally web-app
wide) version selection mechanism for the built-ins libraries (plural:
JS, DOM, and more -- and all libraries, too, not particularly
distinguished by being native or primordial in their specs).
No one has made a proposal to TC39 yet.
The closest thing to (2) being fielded today may be what modern IE
versions [A], and now Google Chrome Frame [B], do with the X-UA-
Compatible HTTP header. David Baron of Mozilla has written cogently
about this header [C].
I'm not in favor of inventing something in Ecma that adds opt-in
versioning of the object model (2), for the reason I gave in reply to
Peter van der Zee: complete opt-in versioning including new API
visiblity is too brittle over time -- it is likely to lead to over-
versioned, under-tested, ultimately non-working (except for one of N
browsers) code. Object- and in general feature-detection is more
resilient and less likely to suffer version-scope-creep.
> 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:
>> 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>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss