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

Brendan Eich brendan at
Sun Apr 18 06:28:27 PDT 2010

On Apr 18, 2010, at 3:56 AM, Peter van der Zee wrote:

> On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich <brendan at>  
> wrote:
> 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.
> Non-string property keys don't need to be hidden. The language could  
> be extended in such a way where identity properties could be part of  
> it. They could be enumerable. Some edge cases would have to be  
> resolved of course.

Existing code containing for-in loops over objects that could be  
passed in as arguments, or found in the heap, where the objects could  
now have object-keyed properties, would break if the keys were not  
converted to strings. But of course if converted to string, an object  
key would lose its identity and potentially collide, and in any event  
not name the same property it did. for-in loop bodies often use the  
enumerated key:

   for (var prop in obj) alert(o[i]);
   for (var prop in obj) assert(typeof prop == "string");
   for (var prop in obj) if (obj.hasOwnProperty(prop)) alert(prop);


This gets back to versioning. If you assume we can make incompatible  
changes to the language, say under opt-in versioning, then there's  
still the problem of mixed versions of code interacting via the heap  
(shared function references allowing new objects to be passed to old  
functions, or just found in the heap by old functions via the global  
object or some other shared mutable object).

These are not "edge cases". They suggest keeping any new object-keyed  
properties non-enumerable by definition, with no way to make such new  
properties enumerable. This then leads to the observations about  
garbage collection, equivalence with inverting obj[prop] to  
prop.get(obj) where prop is an EphemeronTable, etc.

> The hidden properties could just as well be strings. You could have  
> a public enumerable property and one that's private and hidden at  
> the same time.

If both are string-keyed, how would you access both from within the  
"private" boundary? There would still be one bit of difference between  
the keys. I'm not soliciting a full proposal from you here, just  
suggesting this is not a clear enough proposal to evaluate.

> I can see these as distinct, That's why I'm wondering whether  
> everyone is trying to solve one with the other or actually pursuing  
> either one (or both) of them.

The names proposal has advantages beyond what a "private string" key  
idea could have, if there were a way to forge or equate the private  
string key. Names can't be forged.

If the private string key idea is indistinguishable with the Name  
object idea, then we are in agreement. The use of "object" in "Name  
object" is a straw concept currently. Perhaps there should be a new  
typeof result. I addressed this issue here:

"We have extant implementations and real code on the Web that assume  
o[x] will convert an object denoted by x to its string representation  
via [[DefaultValue]] (typically, toString) and use that string to  
identify the property of o. Changing the rules by making Name  
instances be of object type (“object” typeof result, Object type name  
in ECMA-262) breaks this contract. There is no string conversion of a  
Name instance that can be used to identify the property named by that  
instance in an object. Names are different animals from strings and  
objects. Their type (typeof and abstract specification type) must make  
this clear."

> This could be fixed by some kind detection scheme for these  
> directives.

You can't detect new syntax except by embedding it in a string and  
eval'ing the string inside a try/catch.

> But why was versioning going to be a problem at first and not any  
> more?

Because old browsers fade away. IE6 is taking its time but it will go  
away too. More modern browsers all auto-update, crucial for patching  
security bugs and promoting new versions to users who might otherwise  
get stuck at a buggy, unsafe old rev.

> 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 
> .
> /be
> That was my proposal indeed. This also makes it impossible for  
> introducing any and all kind of feature that would not be parsable  
> by previous versions (like introducing new characters or the short  
> function notation). It actually puts a great burden on the evolution  
> of the language as a whole, doesn't it? Not sure whether that's a  
> bad thing per se.

The burden comes from the Web as it is, in my view. We don't get to  
start over. The decision whether or not to make a new and more freely  
incompatible variant of JS is, you're right, a choice. TC39 does not  
propose such a large change. It is likely to be bad for implementors  
and users. It would probably not converge in a usable new spec, based  
on design-by-committee. The odds of a market player evolving some new  
and more incompatible version is even lower.

The best course in TC39's view, I think I can safely say, is to extend  
the language in ways that address design flaws and gaps, and remove  
flawed constructs only after they fall into disuse. It is the  
extension via new syntax, more than extension of standard objects (but  
both can matter), that motivates this versioning discussion. And of  
course this gets back to the thread's topic: why did ES5 add "static  
methods" to Object.

I hope this helps clarify things.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list