Object ID's

[Neil Mix]

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

I see from the discussion page that this may be tied into some sort  
of dictionary datatype?  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.  :(

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?

It's not a particularly strong use case, but my point is that if you  
start from the position of wanting object A to reference object B,  
but object A could be sealed, then there's no stupid-simple way to  
set up the reference.  (OTOH, for unsealed objects it's safe to  
simply add B as a member of A, provided you DontEnum it, which is  
awfully handy and simple.)