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
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'].
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.
More information about the Es4-discuss