Elliot I think that we already took into changes made by nicolas. Stef
On May 19, 2010, at 2:35 AM, Eliot Miranda wrote: > Hi Lukas, > > On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <[email protected]> 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 > > > > > At the very least, the branches of > > index = 1 and: [ #(117 120) includes: self primitive ]) > > ifTrue: [ > > > > REALLY deserve some comments... > > > > Cheers, > > Henry > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
