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
|