Hi Eliot,
What about super sends ?
Object>>beNasty
^self
Collection>>beNasty
self addLast; 1.
super beNasty.
OrderedCollection>>beNasty
self addLast; 1.
super beNasty.
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
