Object ID's

Peter Hall peter.hall at memorphic.com
Mon Mar 26 16:10:50 PDT 2007


> tantalizing knowing they are probably there yet inaccessible.

I think the important word here is "probably". The specification can't
mandate this sort of thing about it should be implementated.


> Are weak-keyed dictionaries already in the spec?

I don't think there is anything in there, weak-ref-wise.


Peter


On 3/27/07, Kris Zyp <kriszyp at xucia.com> wrote:
> 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>)?
> Kris
>
> ----- 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
> >>
> >>
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list