Object ID's

Kris Zyp kriszyp at xucia.com
Mon Mar 26 16:03:48 PDT 2007

Yes, that would be better than nothing. However, I think that the lure of 
unique ids is the idea that the VM surely must be holding some unique number 
for each object, and exposing them would seem not very difficult and 
extremely fast. I don't think unique ids are a real big deal though, just 
tantalizing knowing they are probably there yet inaccessible.
Are weak-keyed dictionaries already in the spec? Will there be no singular 
weak reference objects (like WeakRef<T>)?

----- Original Message ----- 
From: "Peter Hall" <peter.hall at memorphic.com>
To: "Kris Zyp" <kriszyp at xucia.com>
Cc: <es4-discuss at mozilla.org>
Sent: Monday, March 26, 2007 3:11 PM
Subject: Re: Object ID's

> Would you be happy without unique ids being built-in, since you can
> implement unique ids yourself with weak-keyed dictionaries?
> Peter
> On 3/26/07, Kris Zyp <kriszyp at xucia.com> wrote:
>> I wanted to mention a few things about the subjects around
>> objectIds/hashCode/weak refs:
>> First, I would love to be able to define weak references in ES4. I have
>> worked on projects where this would be enormously helpful in reducing 
>> memory
>> usage, and there is simply no way (that I know of) to reproduce this
>> capability (it is much more than making something easier, it is making it
>> possible). To me this would be the single greatest feature of ES4, and as
>> far as the spec goes, does not seem like it would be a difficult
>> addition.Second, I think it would be nice to have access to unique IDs 
>> for
>> objects, that would be helpful in certain situations.
>> Third, in Java hashCodes must NOT be unique in situations where two 
>> separate
>> objects are defined (by the equal method) to be equivalent. For example:
>> String str1 = new String("hello");
>> String str2 = new String("hello");
>> With these two variables str1==str2 should return false and
>> str1.equals(str2) should equal true, and therefore str1 and str2 hashCode
>> must be the same (JavaDocs make this very clear and this is why the 
>> String
>> class in Java overrides the hashCode method instead of using the default
>> implementation that usually returns a unique number corresponding to a
>> memory location).
>> As long as a language allows one to define the meaning of equivalence
>> between separate objects (and those objects can be used as keys in 
>> hashes),
>> hashCodes must not be always unique. Java allows defining the meaning of
>> equivalence by overriding the equal method, ES4 will allow definining
>> equivalence by overriding the == operator, so I would assume it is 
>> necessary
>> that hashCodes not be always unique. I am not sure if this was already
>> articulated, but it didn't seem to be.
>> Anyway, I apologize if this is too late in the discussion, but I do 
>> really
>> hope that weak referencing makes it in the spec.
>> Kris
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es4-discuss

More information about the Es4-discuss mailing list