As much as I would love to donate some code at this point, this will not
happen in the near future due to the many interuptions going on in my life
right now.  So, instead here are some thoughts.

A while back I warned that it would probably turn out to be a very desireable
property that whatever you do with modules, you do it in a manner which is
both reversible and tolerant of the existing tools modifying things behind
your back.  I hereby reiterate that warning.  The stuff I've seen lately does
not appear to have this property. Get it.

Along those lines, what I've been working on in various airport terminals
across the country is one approach to this.  It isn't done yet, isn't that big
a deal, but my time available is very tight right now.  What I am doing is
wrapping every class and method in the system with module-aware wrappers.
That is, objects that facilitate the "paint" metaphor I mentioned earlier.
"Paint" whatever you want, discard that paint scheme, and you still have the
old system, working just as it always did.  Changes done to the old system
while you have it painted are easily tracked through the Change notification
mechanism- this has been done for years in the Refactory tools, and I'm sure
that this is just as viable in Squeak as it is in VisualWorks where I'm still
working ( sorry, but the tools I have there are way more powerful ).  So,
using a regular System Browser you could patch something that has clobbered a
Module Browser, and that patch would be reflected in the painted system as
well.

The other aspect of this is that one could use various forms of Modurization
Chainsawing to get a rough approximation to modular boundaries.  For instance,
partitioning along class category boundaries.   A super duper general purpose
fully automatic scheme to modularize a non-modular image is basically right
out at this point.   Nobody I am aware of can do this.  Human intervention is
required.  But, that doesn't mean you can't whip out the chainsaw and make
some rough cuts at it.  After this, you will need other tools, such as those
for finding classes which are only referenced by the classes of one module,
yet is itself not in that module... but the human needs to decide if it should
be moved.  There are other problems that crop up too, such as finding that the
class hierarchies do not neccessarily like the module partitionings generated
this way ( intermediate classes in the super chain lying outside of a given
module... so how do you load/unload it? ).  There are quite a few things to
find out about, but basically any tools that are created for these tasks will
be most useful if they have a very strong advisory component, as opposed to a
very strong action component.  We're no longer talking about futzing around
with individual methods- you want powerful tools that can rip deeply into a
code base and "extract" ( paint, actually ) great tangled masses of
inter-related stuff into coherent categories.  It's as fun as it sounds!

Since we cannot count on fully automatic fire and forget solutions, but must
make use of manually constructed solutions, it would be very nice to store a
given configuration ( "paint" scheme ) and then share it and reconstruct it in
any given image, even if that image does not neccessarily have the same
classes in it.  Actually, it would be neccessary.  Think of these paint
schemes as being meta-programming constructs, and in particular ones that you
consider to be no more valuable than Kleenex.  Create it, save it, change it,
discard it, easily, and without a second thought.  Avoid getting locked into
any one approach at this point as though it were the plague.  It is much worse
than that.

Advisory mode off... now back to my regularly scheduled job.

- les