The low road to modularity
marcel at system.de
Mon Feb 15 22:11:00 UTC 1999
[ 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.
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 ...
More information about the Squeak-dev