Ben Coman 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.
Ben, I believe you are correct. I did not think deeply enough about how using #= would work. In retrospect, it looks like my hypothesized scenarios would not be problematic. But I will stand by my argument about naming methods. The philosophical technique Reductio ad Absurdum will be useful here. If I began a method declaration as follows, everyone would agree it was bad. fred: another "Answer whether I have the same effect as @another." I believe almost everyone would agree the mistake in that is that the comment should be unnecessary because the method name should explain its purpose. One of the best heuristics I have ever encountered for naming things is to start by "explaining to a colleague" (perhaps an imaginary one) what the thing does, then strip out every word which does not affect the meaning. [This last step would almost certainly prevent the inclusion of phrases like "when executing" in a CompiledMethod method, in my opinion.] > @Max > > I guess to call it a bug, you bumped into a different use case > where [2]=[3] is problematic. Can you describe that? > > > 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. >> >> -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4785205.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
