But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality.
Doru On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxle...@gmail.com> wrote: > > On 17.10.2014, at 02:46, Ben Coman <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 > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > -- www.tudorgirba.com "Every thing has its own flow"
