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

Peter van der Zee ecma at qfox.nl
Sat Apr 17 15:07:41 PDT 2010


On Sat, Apr 17, 2010 at 11:40 PM, Brendan Eich <brendan at mozilla.com> wrote:

> 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 detection.
>
>
> 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.
>
> /be
>
> [A] http://msdn.microsoft.com/library/cc817574.aspx
> [B]
> http://www.chromium.org/developers/how-tos/chrome-frame-getting-started#TOC-Making-Your-Pages-Work-With-Google-
> [C] http://dbaron.org/log/2008-01
>
>
>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

Okay, what exactly are we trying to solve here...

It seems to me there are two things to be solved, there are a couple of
doing it and a few routes to take in general...

To be solved:
- Allow non-string-property keys
- Allow "hidden" properties, non-enumerable, not generically accessible
(like stringed keys are now). To be honest, I'm still not 100% clear on this
one.

Ways of doing that:
- By identity
-- Property is inaccessible once the identity is gc'ed
-- Could cause additional constraints, make an implementation more complex
and heavier in general (circular checks)
- By some kind of private syntax, see the straw for that

Routes in general. By this I mean making changes to the language like
discussed in this thread.

Basically, there are a few options available...

- Simply add new object / instance methods to the language in a sane
sounding way, taking the backwards compat problems for granted. This is by
far the easiest and yet the most opposed way.
- Add new methods with obscure names in an effort to minimize backwards
compat problems. This is what __proto__ would fall under (in my opinion). I
think that's also part of the start of this thread and the comparison to
"that other language"...
- Extending the language by using new syntax, allowing more characters or
sacrificing reserved keywords. This will only get you so far and is not
always the "best" option for certain extensions.
- Versioning opt in. The only ecma generic way I see is by directives.
Script tag attributes are not an option because ecma is a generic language,
not just for browsers. Will come back to this in a sec.
- Freezing ES5 and starting a major version increment. Coming back to this
as well.
- ?

As far as versioning goes, this seems like an appealing option at first but
can lead to a complex system of rules and versions to be kept supporting.
Basically Brendan's objections. Any versioning scheme will come down to
this, whether it be feature specific (like an include) or version specific
(minor/major version or whatever).

Freezing the spec for this major version and starting a new major version
sounds like an interesting choice, to me anyways. Of course I'm not quite
clear on the consequences of such a decision nor whether there's already
work in progress on this. But what about a new major version of Javascript.
One where most of the well known problems are addressed and some interesting
scheme is implemented that allows the language to be extended, while still
keeping backwards compat. Of course this version could also have the nifty
weird language additions waiting to be implemented like let and perhaps
sharp variables. New syntax, extended rules, or whatever.

In fact, I would very much like this because it allows for a "simple"
javascript. The one we have now. And for a new javascript with a whole new
level of complexity. Because frankly, some of the features that have been
proposed scare me a little in terms of complexity. The accessibility and
readability of the language is becoming an issue when they are implemented.

So. What problem are we trying to solve here and what options do we have
(and are viable) to extend the specification?

- peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100418/dd17e6ae/attachment.html>


More information about the es-discuss mailing list