[squeak-dev] Class>>binding broken (was: Re: The Trunk:
nicolas.cellier.aka.nice at gmail.com
Wed Feb 3 07:52:07 UTC 2010
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 ?
>> - Andreas
> Best regards,
> Igor Stasenko AKA sig.
More information about the Squeak-dev