Another perspective on modularity

Michael van der Gulik squeakml at gulik.co.nz
Tue Apr 6 00:02:16 UTC 2004


Hi.

I'm hardly qualified to say something, and I can't put any code where my 
mouth is (don't have a computer at the moment), but I'll say it anyway.

I have an ambition to create a world-wide virtual machine, where any 
object on any machine can send messages to any other object on any other 
machine. Thus, we have a very, very, very big virtual machine. And 
namespaces/modules wouldn't be an option; they'd be absolutely necessary.

Considering that computers are getting bigger, it's logical that 
(Smalltalk) images are getting bigger too. Global namespace pollution 
will eventually become a problem in Squeak. I've already had trouble 
from it.

Dan Ingalls wrote:

> Whatever the module, whether it is a namespace, or a package, or a
> project (which I usually consider to be a combination of the two), or
> even something like an ImageSegment, the first questions asked are:
> 
> If you load a new module, how does it affect the rest of the system? 
> If you remove a module, how does it affect the rest of the system?
> 
> When you put these together, it suggests a desideratum:
> 
> If you load a module and then unload it, you should not be able to
> tell it was ever loaded.

...or perhaps the module was never loaded at all.

What if... each module was an image (and source file) in it's own right, 
and messages were passed between modules. Or at least this is the way it 
appears to work to an outsider, and the implementation could do fancy 
tricks to make it efficient. If message passing is the only form of 
communication between objects, this would work... albeit perhaps slowely.

If there was some way of keeping part of a Smalltalk image separate and 
encapsulated from the rest of the image as, say, a segment, and then 
have <hand-waving>special methods</hand-waving> to "import" or "link" 
those into other segments, we would effectivly have the same 
functionality that name-spaces would provide, but with extra cool 
features such as the ability to make some read-only (e.g. the basic 
kernel), or save them like a project file, or use remote message passing 
to use modules on remote machines, or...

Mikevdg.




More information about the Squeak-dev mailing list