names [Was: Approach of new Object methods in ES5]

David Herman dherman at mozilla.com
Sat Apr 17 12:03:07 PDT 2010


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100417/9bf57aea/attachment.html>


More information about the es-discuss mailing list