Should removed classes become Undeclared?

Bert Freudenberg bert at impara.de
Sun Feb 12 21:39:19 UTC 2006


Am 12.02.2006 um 19:00 schrieb nicolas cellier:

> Le Dimanche 12 Février 2006 14:55, Bert Freudenberg a écrit :
>> If a class is still referenced in code, then removed, and later filed
>> back in, the former references do not point to the newly filed-in
>> class, but to the obsolete former class.
>>
>> This breaks (at least) the unloading and re-loading of Monticello
>> packages. You have to manually recompile all methods that reference
>> the class.
>>
>> Would moving a class to Undeclared be a good fix for that? Or do we
>> need a weak registry for removed classes to be able to efficiently
>> fix up the references later?
>>
>> - Bert -
>
> the association value is nilled out when moved to Undeclared.

Ah, that's a good solution. No need to hold onto the obsolete  
classes, or is there?

Maybe if we want to migrate instances later?

> If you want the association preserved, inverse move operation must  
> be done
> when loading a class, Undeclared keys must be checked and association
> transferred to the SmalltalkEnvironment.

This already happens in the file-in code.

> But this could also have tricky results in a future (?) multi- 
> namespace
> environment.
> Suppose NameSpace A has a class C.
> NameSpace B also has a class C.
>
> If you remove both classes A.C and B.C, then load class C again  
> what happen ?

Nothing - the latest proposal for Squeak namespaces was to just use  
#A::C and #B::C as a class name. Nice and clean.

> The idea of making the whole Undeclared dictionary weak sound a  
> good idea to
> me. You would have non referenced entry garbage automatically. What  
> do you
> think of that ?

Sounds good to me ... unless there is code which relies on  
temporarily moving stuff to Undeclared. I wouldn't rule that one out ;-)

- Bert -




More information about the Squeak-dev mailing list