[squeak-dev] ALL CLEAR (Re: Class>>binding broken)
leves at elte.hu
Tue Feb 2 19:12:02 UTC 2010
On Tue, 2 Feb 2010, Andreas Raab wrote:
> Okay, the issue should be fixed now. If you're at update 8964 or sooner, you
> can just update and won't see any issues. If you're past 8964 already, run
> ReadStreamTests and if they fail, please reload CollectionTests-ar.138
> manually to ensure it's loaded properly.
Great, it works. But two tests are failing now which passed before:
TraitsTestCase >> #testChangeSuperclass
PureBehaviorTest >> #testChangeSuperclass
> - Andreas
> Andreas Raab 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?
>> - Andreas
More information about the Squeak-dev