David T. Lewis wrote:
> On a related topic, I'm not sure how ToolBuilder-MVC (and ToolBuilder-Morphic)
> should be handled. I've been treating package ST80 as equivalent to MVC
> which would suggest changing ToolBuilder-MVC to ST80-Toolbuilder if the 
> primary goal is to have reloadable MVC and Morphic. However, ToolBuilder
> is maintained as a package in its own right, so the current package naming
> is important.

The reason ToolBuilder is structured the way it is is mostly to avoid 
having additional dependencies. Logically, ToolBuilder-MVC depends on 
*both* ToolBuilder as well as MVC being present. One could repackage 
this into ST80-ToolBuilder but that would make ST80 dependent on 
ToolBuilder which is a bad trade in my understanding. I'd like to have 
the option to say "I don't need no stinkin' tools and I don't need no 
stinkin' ToolBuilder either".

> I'm inclined to think that "unload MVC" should mean "unload all of ST80
> plus all of ToolBuilder-MVC plus all methods in other packages in method
> categories *ST80-*". Does that sound right?

Absolutely. If we had better modeling of package dependencies then 
obviously anything that requires MVC needs to be unloaded before MVC can 
be unloaded itself (coincidentally, this is one of the issues I have 
with Metacello: it does not support unloading).

> FWIW unloading and reloading MVC does work, but still requires recompiling
> the sources after reloading the ST80 package. The remaining work is just
> a matter of cleaning up some references to ST80 classes from classes outside
> of the package, which leaves only about 30 remaining issues if I'm counting
> correctly (a very short list compared to where we started).

Wow! That is *great* news.

Cheers,
   - Andreas