Anno Siegel wrote:
It is true that a string comparison of two references is true if and only
if the references are the same.
I thought so, too, when stringification enters the picture they can be equal
only when their types and addresses are exactly the same. But still, hmm,
you cannot have references to two different types pointing to the same
memory address, of course, so on second thought the address is a unique key
alone.
The strings that are compared may not be the same each time.
Is this because of possible garbage collection, or scalars growing or
shrinking automagically? Hmm speaking of hash keys, my understanding based
on some other languages is that they must depend on the object's state to be
able to work consistantly. But if you use a stringified memory address and
the address changes later on independent of the blessed thing's state, you
cannot just dereference the same blessed thingy to reuse it as a key in
indexing. Many other languages let you freely use objects or whatever else
you like as hash keys. ARe there any workarounds for Perl? One possibility
that came to mind would be to use Data:
umper and compute a hash value
based on the object's state. Can I somehow access Perl's internal hashing
function for keys to hash my own data, similar to Java's hashCode method?
I do realize Perl is not the same as Java, far from it. Still browsing the
docs for the hashCode method for the Object class, I noticed this contract
for hashing which might be widely applicable. Quoting JDK 5.0:
- Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals comparisons
on the object is modified. This integer need not remain consistent from one
execution of an application to another execution of the same application.
Interesting, so the internal state may change and you're allowed to return
the same hash code as long as the equality of the object, as far as the user
goes, is not altered. Maybe my suggestion about simply dumping the blessed
thingy's internals isn't wise after all.
- If two objects are equal according to the equals(Object) method, then
calling the hashCode method on each of the two objects must produce the same
integer result.
- It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on each of
the two objects must produce distinct integer results. However, the
programmer should be aware that producing distinct integer results for
unequal objects may improve the performance of hashtables.
Hmmm don't these last two statements contradict each other? At least on an
initial read, the first seems to say that if two objects of the same Class
return the same boolean for equals, you must return the same hash codes.
However, the second one effectively mitigates the first by saying that if
they produce different boolean values for equals, they don't have to produce
different hashcodes. So as far as I can see, you cannot tell based on the
hash code whether two objects are equal. The hash codes can be the same if
they are and they can still be the same if they aren't. What's the use of
being able to use objects as hash keys then? Perhaps I'm again missing
something fundamental here.