Wow, compelling example! Alexandre
> On May 29, 2015, at 12:33 PM, Henrik Johansen <henrik.s.johan...@veloxit.no> > wrote: > > 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 >>> >>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
