Object ID's

Peter Hall peter.hall at memorphic.com
Wed Mar 21 06:46:15 PDT 2007


FWIW, The standard Flex Framework contains the string "new Dictionary"
19 times, of which 10 are weak keyed.

Peter


On 3/21/07, Brendan Eich <brendan at mozilla.org> wrote:
> 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
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list