What *does* matter is to begin seeing what is going on when you try to herd all those cats into a nice orderly modular world.  And it would be very helpful if you were cut a bit of slack in the early stages.  A lot of slack would be better.  In particular, I've been thinking that it might be useful if you were to go ahead and introduce modules now, but in a fashion where they are more or less just decorations.  That is, go ahead and use the existing environment variable on the classes to point to bona-fide modules in whatever scheme you pick.  But don't let it mean too much just yet- the classes would still be reachable through the Old Reliable means of the SystemDictionary Smalltalk, and your existing code tools would work no differently than before.  Think of the module system as being no more valuable to you than a thin layer of paint- don't get too attached to it just yet.  But go ahead and build new tools that use it, tools that realize that the older non-modular tools may do things behind their back.

Les -

This is a GREAT perspective on getting started.  When I first started on Environments, I spent a day just reworking the systemOrganization to where it began to show some of what we are after.  The I started attributing meaning to the major categories...

>I have several reasons for suggesting this.  One, obviously, is that it would be nice to try out different modularity schemes over time.  But that isn't the most important reason at all.  Easily the most important ( well it comes to mind quickly in the middle of the night, at any rate ) is to avoid the Class Initialization Problem.   You don't want to tackle this yet.  It will have to be handled, but not today.

Yes.  But even if we go a bit farther this need not be a problem.  I would be quite happy to have a module system that organized Squeak in a way that we liked, but where a couple of core modules were still incapable of self-initialization.  For those, for now, they can remain part of the release, and we'll care more about unloading them (for really tiny kernels) than about loading them (since they are shipped as part of the image).

>So this brings me to a second suggestion- just as we have an environment variable for classes ( and rightly so, AFAIK ), if we add an environment variable to CompiledMethods ( or a subclass which can be used by recompiling all methods in the system ) then you have a mechanism to keep track of which methods in a given class are "native", and which ones are really there because some other module wanted them there.  This would be a crutch- I am not seriously suggesting this as a long term solution.  Perhaps it is, but I don't have any insight to that at this stage.  But if you did this, and had the tools to help you discern whether a given method belonged to the module in which its class is defined, or should instead be listed as an extension method provided by another module, I think you could get rolling relatively quickly. 
Les, I don't think you need anything this deep.  I think it would suffice to put this info in the nascent modules.  It would not be hard to keep it up to date with a little hook in Behavior>>compile, and it wouldn't be all that hard to sweep the system again to bring things back in line until we have it all right.  We'll be doing this anyway while we juggle things around into a nice factoring.

>So, I guess what I'm proposing for this early stage of the game is a form of weak modularity, hopefully one that can grow gracefully into a strong modularity.

I think this is a wonderfully liberating approach.  Merely installing such a weak module system enables us to then work on

	A good factoring of the monolithic image

	Enhancing our tools to work with modules

	Shrink methods that really work
	(think of this as unloading weak modules ;-)

	Various candidates for strong modules

Thanks for an empowering middle-of-the-night point of view.

	- Dan
--