Should removed classes become Undeclared?

nicolas cellier ncellier at ifrance.com
Sun Feb 12 18:00:22 UTC 2006


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 -

That's what is done in VW. Removed classes are moved to Undeclared
(in fact, this is so any removed entry from any name space, not only 
Smalltalk).
In VW, the association value is nilled out when moved to Undeclared.

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.

I think this would solve most of your Monticello problem.

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 ?
Should every namespace have its own Undeclared ?
Or should Undeclared have several times the same key (not a Dictionary 
anymore, but a Set of Associations...) ?
In VW, i do not know how they handle this case...

Without namespaces, there might be over tricks, because Undeclared can also 
contains reference to a remove inst var or class var...

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 ?




More information about the Squeak-dev mailing list