Andreas Raab wrote:

> Thus the "neighbor modules" are the prerequisites. I got caught by that
> too (as well as by "definedNames" and "exportedNames" which hold the
> actual objects not just their names as I initially assumed). Perhaps we
> should rename these variables accordingly (e.g., "prerequisites",
> "definitions" and "exports").
> 

Sounds fair to me, but I think "dependencies" is clearer than prerequisites,
because it also serves the purpose of defining what other modules your
module can access names in.

> My feeling is really that we need to cut a few rough lines through the
> system after which we can establish finer areas of control. And I also
> think you could more easily establish a "working group on cutting out
> everything 3D related"

That already works. see

http://minnow.cc.gatech.edu/squeak/UnloadingModules

This and other info has been at

http://minnow.cc.gatech.edu/squeak/Modules

for some time. Now that's a pretty easy-to-remember place on the swiki, no?

danielv at netvision.net.il wrote:

> Yes, that's true, but I think, (Idon't know) that most of the modules in
> the system now do not have proper declarations unless someone (Henrik)
> has already readied them for removal. So the list is a reasonable
> approximation (see * below).

The reason is that there isn't much point in declaring these until a module
has been properly refactored. Until that point, its dependecies will look
much like a random list of other modules in the image. You can use "module
localUnresolvedRefsPerModule explore" to compute the implicit dependencies
from the code in a module.

So when a module has been refactored, so that its complete list of
dependencies "makes sense", then it also makes sense to declare the
dependencies. 

> 1. Actually, I think Balloon3D is already supposed to unload as one of
> the examples. Though it still doesn't for me.

Have you tried

http://minnow.cc.gatech.edu/squeak/UnloadingModules

? It seems to work for me.

Henrik