Hey, Dan, for some reason I missed this email previously, or I wouldn't have proposed using hashcode. I think you put the final nail in the coffin :)

I am working on a more complete response to your last email, I'm trying to think this all through :)

David

Daniel John Debrunner wrote:
Jack Klebanoff wrote:


If the Derby client absolutely requires that its Connection class
toString methods return unique, that is if the client would fail to work
if toString() were not unique, then we could toString could not use
identityHashCode. However, I do not believe that this is the case. I
think that uniqueness is very helpful but not required.

It is true that identityHashCode is not guaranteed to be unique.
However, in practice it almost always is unique.


I'm not sure about that. If the identity hash code maps to a memory
address then the fact that the object's hashcode has to remain fixed
over time and objects can be moved in memory mean that two objects could
 end up with the same hash code. Ie. the are created at different times
but at the same address, since the first object created has been moved.

Dan.


Reply via email to