Hi Les!

[ simple module system ]

> Done... although not in the manner you will want ( just yet ).
> In my system these imported things are kept inert, but it is also
> possible to let these things be active.  To do this requires
> module-savvy classes, compilers, parsers, scoping mechanisms,
> etc- otherwise one gets "leaks" into the normal image.  But I already 
> have most of this in VisualWorks- only missing the non-inert versions 
> of the classes, due to my emphasis on analysis of the inert classes.   

Actually, what I am thinking about is rather *less* than what you  
are outlining (I did call it the *low* road to modularity...).  The  
idea was that most of the system is really quite static, so it should  
be possible to separate the static bits from the changing parts,  
similar to sources/changes files.

The CompiledMethods for most of the system make up just such a large  
static chunk, so it should be possible to link them into the VM  
without loading them.  If you can link/reference one static chunk,  
doing the same with several different chunks isn't that much harder.   
Instant modules.

This is a very simple mechanism, you could call it brain-dead.  It  
doesn't even attempt to deal with inter-module dependencies or with  
the massive coupling in the present system.  If everything is  
present, fine.  If not, tough luck.  If methods are multiply defined,  
last one wins.  KISS.

Why am I advocating such a brain-dead scheme?  Because I think that  
the basic elements of a system have to be as simple as possible (and  
maybe even a bit simpler :-).

Now I probably get to build it ...

Marcel