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 -