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-tp4784722p4784... 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-tp4784722p4785... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.