On 17 Oct 2014, at 11:12, Tudor Girba <[email protected]> wrote: > 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.
From a modelling standpoint it sounds as if one object (CompiledMethod) is used for two different things which results in the conflicting ideas about implementing equality and hashing. A CompiledMethod should hold a CompiledCode object while adding the selector and class. The CompiledCode object could then be equivalent or even be optionally shared among similar methods (like all those implementing ^self). Just an external observation / idea. > 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. >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"
