On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli
<renggli@gmail.com> wrote:
> Same method in different classes do not �equal eachother though, if I've not made a mistake in:
>
> |mrtCp|
> mrtCp := (InstructionClient>>#methodReturnTop) copy.
> mrtCp literalAt: 2 put: #ContextPart->ContextPart.
> (InstructionClient>>#methodReturnTop) = mrtCp
For methods that send super the behavior changes if you change the
class binding. That's probably why it is not ignored for #=.
In fact I would suggest to #= from compiled method altogether, in most
cases it doesn't do what one would expect in a given context anyway.
There are too many and possibility completely different
interpretations of #= for CompiledMethod. #== is the only decent
implementation for this class.
I sympathise but I think there is a reasonable default interpretation of #= for CompiledMethod that is what most people want. �The intent is to answer whether two methods have the same execution semantics and same method tags & properties, e.g. if one were to compile the same source code in two different classes that had the same inst var offsets for the inst vars in the methods, then one would want those methods to be #=. �This allows tests such as
- checking whether a subclass has a method that is #= to a superclass, and is hence redundant.
- checking whether a set of sourceless methods are equivalent so that they may be shared under different selectors (e.g. think auto-generated accessor methods which can be cached and shared)
So for this informal definition the selector and the class are irrelevant, but bytecodes and literals (apart from the selector and method class literals) are relevant. �Its almost a short-cut comparison of error-free decompilation, although there are differences in the bytecode that wouldn't show in decompilation (e.g. using long branches for short branches).
The current definition serves for compiler hackers as it tells you accurately whether a compiler change has an effect on the bytecode, can be used to test whether compilation followed by decompilation followed by recompilation has an effect, etc. �While it may not be a universal code comparison method it has met my needs throughout the closure compiler so at least I'm pretty happy with it.
(pleading for CompiledMethod>>#= to stay the same as the current Squeak 4.1 definition, which ever since Nichoas Celier's float compilation changes, is pretty darned good).
best
Eliot
Lukas