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 ?