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

Brendan Eich 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  
style

<script src="harmony.js" type="application/ecmascript;version=6"></ 
script>

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

http://wiki.ecmascript.org/doku.php?id=proposals:versioning

An in-language pragma, e.g.

<script>
"use vesrion 6";
// Harmony code here...
</script>

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 
.

/be


More information about the es-discuss mailing list