Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality.
And I am also of the opinion that equality should take the name of the selector and even the name of the class into account. Doru On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <[email protected]> wrote: > > On 17.10.2014, at 09:37, Tudor Girba <[email protected]> wrote: > > But why is Set being affected by hash? Hash is never guaranteed to be > unique. Set should be affected by equality. > > > Well, actually it’s both #hash and #=. First the set tries to find a > suitable place for the element using the elements hash. If that place is > already taken it then checks equality. Since the equality definition is > mostly the same (same literals, same byte codes etc.), the second element > is rejected because it’s already in the set. > > > Doru > > On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <[email protected]> wrote: > >> >> On 17.10.2014, at 02:46, Ben Coman <[email protected]> wrote: >> >> Richard Sargent wrote: >> >> Eliot Miranda-2 wrote >> >> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >> >> richard.sargent@ >> >> wrote: >> One of the best things about Smalltalk is how easily we can say what we >> mean. I think you would be better off creating a method named something >> like >> #hasSameEffectAs: to answer what you are presently using #= to do, and >> change #= to answer the, in my opinion, more sensible "is the same as" >> that >> we conventionally think of #= meaning. >> >> But that's the point. #= has to mean something and having it mean #== >> isn't useful, so one has to choose some value-based semantic for >> CompiledMethod>>#= and the one that's there is useful. Defining what #= >> means for some value type is far easier than defining what it might mean >> for something as complex as a CompiledMethod. The definition in >> Squeak/Pharo has been useful to me in implementing a closure-based system, >> so I'm unapologetic about the current definition. It is a good one but it >> doesn't preclude defining others. >> >> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >> provides greater clarity and add an argument against something I didn't >> say. >> I also don't think defining equality for a CompiledMethod is particularly >> difficult. If I were to recompile a method's source code, I would get a >> new >> instance of a CompiledMethod that would, in my opinion, be equal to the >> one >> already installed in the class (and perhaps cached in the VM's >> optimizations). So one would be able to say that we would not replace an >> existing CompiledMethod with an equal one. The current implementation of >> #= >> has no such characteristic, since it proclaims a CompiledMethod named #a >> to >> be equal to one named #z. >> >> >> @Richard >> >> That doesn't seem to be a good example for what your trying to say. >> Given... >> >> [1] SomeClass>>a "original instance" >> ^1 >> >> [2] SomeClass>>a "recompiled instance" >> ^1 >> >> [3] SomeClass>>z >> ^1 >> >> ...you seem to be saying that its useful to know if [1]=[2], >> but imply that is invalidated by [2]=[3] ? >> >> But [1]=[2] remains true, and just as useful for your example. >> >> >> @Max >> >> I guess to call it a bug, you bumped into a different use case >> where [2]=[3] is problematic. Can you describe that? >> >> >> Well, not problematic. Once you accept that neither selector nor class >> are part of a CompiledMethod it is obvious that two instances with the same >> byte codes produce the same hash. >> >> The actual problem is more one of understanding and use. The following >> code answers a collection with the CompiledMethods Collection>>add:, >> Collection>>do: and Collection>>remove:ifAbsent: >> >> Collection methods select: #isAbstract. >> >> >> All three CompiledMethods are implemented as ‘^ self >> subclassResponsibility’, so they have the same byte codes. Now, if you take >> that collection and make a set out of it you’ll lose Collection>>do: since >> #do: and #add: produce the same hash, but #remove:ifAbsent: doesn’t because >> the number of arguments is calculated into the hash (actually the >> CompiledMethod header is). >> >> So, as long as you think of CompiledMethods as objects that have a name, >> it looks like a bug and in my opinion this behaviour is something that >> messes with the mind of newcomers. Just a (silly) idea: something like a >> CompiledMethodWrapper might solve the problem (at least from the user >> perspective; everything is slightly different from the VM perspective :) ), >> as it could hold on to the class and the selector independently of the >> actual CompiledMethod. >> >> In the end however, one doesn’t work with compiled methods a lot and the >> hash situation is unlikely to cause a lot of problems (people working with >> CompiledMethod usually know what they are doing). >> >> Cheers, >> Max >> >> >> >> cheers -ben >> >> >> The blue book say #= means "Answer whether the receiver and the argument >> represent the same component." The current implementation does so only for >> some, in my opinion, counter-intuitive definition of "same component". >> -- >> View this message in context: >> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com <http://nabble.com/>. >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"
