The last few weeks we've seen a tremendous amount of discussion on bringing 
modularity to Squeak, and I know that some of you are really itching to get on 
with the show.  The last few weeks I've been dusting off a few things, 
reconsidering others, and generally getting back into the swing of things.  I've 
thrown out a few cautions, but hopefully these are not overly pessimistic.  The 
inventory of working code waiting just offstage is actually rather impressive, 
and I'm not just tooting my own horn here ( the same would be true if none of my 
stuff had ever been built ).  I wish I were in a position to throw out Oasis to 
the masses and say "here's your answer, live long and prosper!", but that won't 
happen for a while yet- I still have some things to explore there before I'll 
have time to release it.  So, out of practical concerns, I'm basically limited 
to making a few comments here and there.

The last couple of days I've been pondering how to move Squeak forward, but 
perhaps without getting bogged down in some of the potholes that I've 
encountered while building Oasis.   Bear in mind that I am not claiming that 
there are any quick and easy shortcuts- I shall judiciously avoid using the word 
"just", for instance- I've come to really find that word to be annoying.

In the early stages, it will not much matter how you build modules, or what 
characteristics they have.  If you have *some* kind of module system, the code 
it handles can be transferred to a different module system at a later date when 
the issues are better understood and you can see where the deficiencies really 
lie, not just where you anticipate them lying.

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.

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.  Example: in Oasis I can and do load the entire class 
libraries of many different Smalltalk dialects.  But to no avail- you can't 
initialize them because they are way too deeply non-modular.  Just can't get 
there from zero, or so it seems, certainly not without some doing some pretty 
fancy stuff, or just accepting the fact that you have to start with a completely 
new class library.  If I could, then I could run into the next problem on the 
list, which is along the lines of "What to do about nil?" and so forth.  But 
Allen says I can get around that, so I won't worry about that for now. ( 
actually, I can get around this by using PocketSt, but that's not my point ).

If you side-step the CIP, you can have modules as soon as you define class 
Module in your likeness.  The first thing you will notice is that there 
certainly are an awful lot of methods out there that your modules are providing 
for classes that they don't define.  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.  You would have to be tolerant of the Old Reliable tools 
creating these new CompiledMethods without giving them a reference to a module, 
but that would be easy to accomodate with the new tools.

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'll give it some more thought, and will try to give this a try 
both in Squeak and in my Oasis development image to see how well it works 
sometime this weekend.  (These things almost never work so easily)

Take care!

- les