Object ID's

Lars T Hansen lth at acm.org
Tue Mar 20 16:30:52 PDT 2007

On 3/16/07, Neil Mix <nmix at pandora.com> wrote:
> On Mar 16, 2007, at 4:23 AM, Lars T Hansen wrote:
> > IMO we'd be better off following Java here and just spell out (more)
> > clearly that you can't use the hash code as an object ID.  The purpose
> > of intrinsic::hashcode is after all to allow fast object-identity
> > hashing.  The use case for object IDs seems less clear.
> Here's my problem: if one doesn't understanding the context behind
> intrinsic::hashcode, it looks like a bug:
>    var key = new Widget();      // our unique lookup "key"
>    var val = new Acme();        // value to reference
>    var hash = {};               // our "hash table"
>    var keycode = hashcode(key); // our hash table key
>    hash[keycode] = val;         // UNSAFE

Sure, but the most I can do is write a clear spec.  If a programmer
reads guarantees into the spec that are not there (or indeed does not
understand the non-guarantees spelled out) then there's not much I can

> I see from the discussion page that this may be tied into some sort
> of dictionary datatype?

So far we've failed to put a Dict type into the language; the utility
is understood but there's not been a critical push.  At this point it
may have been back-burnered long enough to be postponed until 5th

> I'm having trouble understanding the use
> case for this otherwise.  Sorry if I'm missing the point of this
> feature, the context available in the docs is either missing or over
> my head.  :(

It's useful for building good hash tables that can use any object for a key.

> The use case that brought me to wondering about this was some vague
> brainstorming about a generic data binding architecture.  Given that
> es4 has sealed objects, the only way to safely reference a dependent
> object from its "data source" is to a) create a wrapper object (which
> could get expensive) or b) use a lookup table.
> But, there's no way in the current spec to use a sealed object as the
> key in a table, unless you implement your own lookup mechanism that
> accounts for collisions, but then again it seems a bit silly to
> implement a hash table in JavaScript, doesn't it?

Not particularly.  Objects are nice and clean, they map strings to
values.  Mapping arbitrary values to values is useful sometimes but
less rarely needed in my experience.  The language could provide a
built-in library (or even syntax support) for it, but ECMAScript is
not Java and the language probably should only provide libraries that
have substantial utility across the user base (just my opinion).


More information about the Es4-discuss mailing list