Wow.....the conversation went far away from my understanding and knowledge. I will try to read it slowly and carefully, several times and try to understand what you said.
For the moment (just my needs) the solution from Lukas worked: use IdentitityDictionary instead of Dictionary. Now I let you to you to decide if it is a bug or not, if it deserves comment, etc. Thank you very much. Mariano 2010/5/19 Eliot Miranda <[email protected]> > > > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
