Also implied, but seldom stated, is that all values used in = and hash must only be set at creation, never after. The reason is the same, keeping hashed collection usage sane; p := Point x: 3 y: 2. Set add: p. "Imaginary method" p setX: 2. Set includes: p -> false
Cheers, Henry > On 26 May 2015, at 9:11 , Julien Delplanque <jul...@tamere.eu> wrote: > > Thanks, I understand now :) > > On 26/05/15 21:06, Carlo wrote: >> Hi >> >> Any two objects that are = must answer the same #hash value. >> The hash is used in any of the HashedCollection's for storage and then to >> find the exact element the #= is used. >> If 2 objects are #= but their hash values are different the HashedCollection >> will not find the correct storage slot and you will have undefined behaviour >> when looking up objects. >> >> Out of interest, Andres Valloud wrote a whole book on 'Hashing in Smalltalk' >> (http://www.lulu.com/content/1455536) >> >> Also the Javadoc comments are pretty good in explaining the usage: >>> The general contract of hashCode is: >>> 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. >>> 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(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 hash tables. >>> As much as is reasonably practical, the hashCode method defined by class >>> Object does return distinct integers for distinct objects. >> Cheers >> Carlo >> >> On 26 May 2015, at 8:45 PM, Julien Delplanque <jul...@tamere.eu> wrote: >> >> The subject of this mail is exactly my question. >> >> I came to this question by looking at Object>>#= message implementation. >> >> """ >> = anObject >> "Answer whether the receiver and the argument represent the same >> object. If = is redefined in any subclass, consider also redefining the >> message hash." >> >> ^self == anObject >> """ >> >> When do we need to redefine #hash message? >> >> Is it the right way to implement equality between two objects or is there >> another message that I should override? >> >> Regards, >> Julien >> >> >> > >
