2010/2/3 Igor Stasenko <siguctua at gmail.com>:
> On 2 February 2010 19:47, Andreas Raab <andreas.raab at gmx.de> wrote:
>> Levente Uzonyi wrote:
>>>
>>> After updating my image, most tests in ReadStreamTest fails or raises an
>>> error. If I open a Monticello Browser, select CollectionTests and Trunk,
>>> click changes, I see lots of methods changed. So this is probably a new MC
>>> issue. Loading the .mcz from the Trunk solves the problem.
>>
>> This is an interesting issue that arises from the new traits implementation
>> but its root cause is elsewhere. What happens is that when reshaping a class
>> that uses traits it may "loose" it's local methods due to Class>>binding
>> being just plain wrong. When reshaping a class, a new class is created in
>> which the methods get compiled but due to the incorrect usage of
>> Class>>binding these newly compiled method will bind to the old class.
>>
>> The only reason this works at all is that at the end of the reshape we do a
>> forward #become: which corrects this problem but the installation of the
>> traits happens before the #become: has fixed them up.
>>
>> There are two possible solutions: Fix Class>>binding to test whether the
>> association actually points to the class. This is straightforward but has a
>> major disadvantage - it means that when adding ivars and stuff we will
>> create new bindings for every method. Effectively that makes the class
>> binding unsharable unless one adds another .
>>
>> The alternative is to defer the installation of traits until *after* the
>> reshape is complete. This is not exactly trivial either but it would avoid
>> the issue raised above.
>>
>> Opinions? Other alternatives?
>>
>
> - a compiled method's methodClass should always point to a class
> object, which owns a method dict where that method installed to. There
> should be no excuses in what shape a class object currently are (like
> transition from old class shape to a new one),
> because assignment of wrong methodClass could lead to fatal error(s) in VM.
>
> So, i assume that current implementation is incorrect, because it
> installs a method and violates that rule.
> Please, no deferring, because it causing more problems (leads to more
> complex code as well as putting extra responsibility on tools, which
> loading the code to take care of this issue).
>

Doesn't this raise the problem of super semantic in a trait ?

Nicolas

>> Cheers,
>>  - Andreas
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>