I agree completely. However - 
1. Actually, I think Balloon3D is already supposed to unload as one of
the examples. Though it still doesn't for me.
2. I didnt say this is a perfect list of easy modules, just ones that
had few externally used classes.
3. My preceding post gave a list of other criteria to be used. Those
said to look for the outer layers (applications), to find small atomic
units and to initially avoid SqC/Morphic code. I simply didn't have code
snippets to detect those rules at hand... ;-)
4. I agree with your argument, but I personally prefer to make my first
bite smaller than taking out a whole chunk of image. 
5. Many of us can find a small chunk and clean it up. Few people can
make the large division. Of those few, fewer have spoken... I prefer to
do what I can in the meanwhile, if it'll help any. I think it can, maybe
I'm wrong.

Using the other criteria to cull the first list (1 class), but without
yet looking into specific modules, I'd probably propose these to start
with:

Squeak Language Exceptions Tests
Squeak Technology Archives Applications
Squeak Media Movies Obsolete
Squeak Morphic Demo Games
Squeak Morphic Library Genie Integration
Squeak Network Library HTML Tokenizer
Squeak Network Library MailAddress
Squeak Network Applications WebBrowser
Squeak Network Applications IRCChat
Squeak Development ProcessBrowser

And maybe just maybe -
Squeak EToy Buttons
Squeak EToy Communication

Daniel

Andreas Raab <Andreas.Raab at gmx.de> wrote:
> Daniel,
> 
> I might point out here that the structuring level is partly inadequate.
> If I look over your list, then I immediately notice that...
> 
> > Squeak Media Balloon3D Alice Misc
> > Squeak Media Balloon3D Alice Scripts
> > Squeak Media Balloon3D Alice Undo
> > Squeak Media Balloon3D Alice Interface
> 
> ... the class references you're seeing are almost certainly coming from
> Alice internal references. It seems unwise to me to have a very fine
> granularity level at this early stage of refactoring. As an example, I
> am pretty certain that _none_ of this Alice stuff is referenced from
> anywhere but within Alice itself. Thus it should unload with no further
> action required. And it appears to me that by using the fine grained
> structure at this point we'll be left with figuring out how to bend over
> backwards in the module system just because the structure doesn't fit
> yet. Making the above unloadable as separate modules might be a nice
> exercise if you want to understand what kind of issues you might run
> into in a module system (since I'm pretty certain there are all kinds of
> circular references) but it's an absolutely pointless exercise if you
> want to make actual progress. So why not go for it and unload just _all_
> of it in a single module?!
> 
> 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" rather than finding somebody who knows how to
> make "Squeak Media Balloon3D Alice Cast AliceConstants" unloadable ;-)
> 
> Note that having large parts go first will also help to establish
> cleaner lines later on. Since we really don't understand yet what the
> boundaries ought to be it just feels right to say 'we have an "Alice"
> module' and later - when we understand how this is separated -
> restructure it in a more appropriate way and just make the new internal
> structure a prerequisite of "Alice" so that anyone relying on "Alice"
> will still be able to use it even if later refactorings are applied.
> Right now this is worrysome for me because with this fine-grained
> approach we are relying on structures which we already know to be
> inadequate (at least for the 3D stuff this is certain).
> 
> Cheers,
>   - Andreas