Object ID's

Brendan Eich brendan at mozilla.org
Tue Mar 20 22:13:20 PDT 2007


On Mar 20, 2007, at 6:34 PM, P T Withington wrote:

> I think having a pollution-free dictionary type would be much more
> important that the `=>` syntax shortcut.  Having a dictionary that
> can map values to values would be a bonus, but also important.  You
> can't do either of these things efficiently in the language, which is
> a good reason to make them built in.

You're right. I thought so when I brought this up a couple of months  
ago, and got "no new features" as the auto-reply. As Lars notes, that  
is very likely to be the answer again, but I'm willing to try one  
more time.

I would like a value -> value map unpolluted by prototype delegation.  
The string -> value map without pollution can be implemented by  
converting arbitrary keys to string and using the value -> value map.

As noted previously, objects in ES4 (which introduces Name objects to  
represent namespace-qualified property names) and ES3 with E4X (which  
calls Name QName) map not just string -> value, but (string, Name) ->  
value. o.q::n is not the same as o['q::n'].

The http://developer.mozilla.org/es4/proposals/catchalls.html  
proposal leaves ident untyped, but it can't be of type *. Practical  
implementations that I know of would type it (int, string, Name) or  
something similar (int might be constrained to fewer than 32 bits in  
a tagged word). Catchalls therefore look tempting for building value - 
 > value maps, but without changing the inside of every ES3  
implementation to treat property names as arbitrary values instead of  
interned strings and tagged ints, or possibly qualified-name objects,  
the key type will be constrained.

So a value -> value map looks like a very special object, not  
something accessed via o.p or o[i] or o.q::n or o.q::[i]. This brings  
us back to the Flash Dictionary class (http://livedocs.adobe.com/flex/ 
2/langref/flash/utils/Dictionary.html#methodSummary) from AS3. Note  
the weakKeys constructor parameter. This class does suffer prototype- 
delegated pollution, but does not intern its identifiers, instead  
using === to partition values into key equivalence classes (so -0 ===  
0 and NaN !== NaN).

Do we want a class that has magic (special-cased) property lookup  
rules, that does not delegate to Object.prototype, and that somehow  
can be operated upon without the standard methods from  
Object.prototype, or overrides for these (e.g., toString)?

I think not. The minimal solution, for which intrinsic::hashcode was  
devised, is a class with methods you have to call, say has, get, and  
put. No property lookup syntax for testing whether a word is in the  
dictionary, and no literal syntax for constructing instances by  
writing the key/value pairs in succession. But it could be part of  
the standard, so you could count on it everywhere. It could be  
written in ES4 if it were acceptable to hold only strong references  
to the keys.

Would this be enough? If so, I think TG1 ought to consider it. It  
would be a small addition to the standard library.

Flash Dictionary users who rely on weakKeys = true should pipe up for  
the use-cases that require this.

/be



More information about the Es4-discuss mailing list