> On 17.10.2014, at 09:37, Tudor Girba <tu...@tudorgirba.com> 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 <maxle...@gmail.com > <mailto:maxle...@gmail.com>> wrote: > >> On 17.10.2014, at 02:46, Ben Coman <b...@openinworld.com >> <mailto:b...@openinworld.com>> 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 >>> >>> <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 <http://www.tudorgirba.com/> > > "Every thing has its own flow"
