On Wed, May 19, 2010 at 4:58 AM, Nicolas Cellier < [email protected]> wrote:
> Hi Eliot, > What about super sends ? > > Object>>beNasty > ^self > > Collection>>beNasty > self addLast; 1. > super beNasty. > > OrderedCollection>>beNasty > self addLast; 1. > super beNasty. > Good point. I still find the existing #= definition very useful for compiler verification. > > Do you think you can remove OrderedCollection>>beNasty ? > > Nicolas > > 2010/5/19 Stéphane Ducasse <[email protected]>: > > 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 > > > > _______________________________________________ > 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
