names [Was: Approach of new Object methods in ES5]
brendan at mozilla.com
Sat Apr 17 22:19:21 PDT 2010
On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
> 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.
I don't see how these two differ.
> 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
The private syntax is so you can use o.p instead of o[x] where x is a
Name object; private p would bind the name p lexically to a Name
object and use it instead of the string "p" when evaluating o.p.
> - 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.
This is what ES5 did.
> - 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"...
This is not favored by TC39, because the __ convention is no guarantee
against collisions, and it is rejected by some sanitizers.
> 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).
Real web experience suggests feature-testing, or really object
detection, is less combinatorial explosive. Once a browser supports
the new object, the script can use it. No need to enumerate browser or
rendering engine names in a conditional or X-UA-Compatible header.
> So. What problem are we trying to solve here and what options do we
> have (and are viable) to extend the specification?
For Harmony we have new syntax, so the problem is clear: we need some
kind of opt-in versioning mechanism for authors to use, where old
browsers do not process the new version. This could involve RFC 4329
<script src="harmony.js" type="application/ecmascript;version=6"></
but then the question becomes: how does the content author ship an ES3
or lower script to older browsers? See the older versioning page I
wrote, which Collin Jackson worked on too, at
An in-language pragma, e.g.
"use vesrion 6";
// Harmony code here...
would be ignored by older browsers. This seems bad because downrev
browsers would try to run the script content, unless you use server-
side version detection to ship this only to uprev browsers.
Harmony having new syntax does not mean we are opening up the design
space to make some new, incompatible version of the language. You seem
to allow for that as a possible future course, but TC39 members are
uniformly against this path AFAICT. See http://wiki.ecmascript.org/doku.php?id=harmony:harmony
More information about the es-discuss