> On 17.10.2014, at 11:39, Sven Van Caekenberghe <[email protected]> wrote: > > > 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.
Yes, pretty much what I was thinking. I don’t know what the consequences would be for the VM though... > >> 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" > >
