Musings about modularity and programming in the large

Jason Johnson jason.johnson.081 at gmail.com
Sun Jan 20 16:30:34 UTC 2008


Hi all,

Recently working in other high level languages I was thinking about
how modularity is accomplished in these systems and how we might do it
in Squeak.

Now we could of course simply add something trivial that formalizes
the prefixes we are using now and hide them for us (sometimes), but
this doesn't really help our position much or make us much better at
"programming in the large".

Looking at other systems, Haskell, Ocaml and Lisp, it is interesting
how they tackle this problem.  What these systems all have in common
is a pretty simple idea: a module declaration defines what is
"exported" or visible from outside the module (or at least can be made
so) and everything else is only visible to code inside the module.

So combining this simple concept with Smalltalk's unique "objects all
the way down" philosophy it occurred to me that a module could appear
as simply a class like any other.  The typical "import" mechanisms
could be ignored, and export is handled as it is now.  That is, today
all classes and objects "export" methods; they simply respond to the
ones they implement and DNU the ones they don't.  Today, in Squeak all
classes are inserted into a global namespace and are therefor visible
from anywhere.  With this module system I'm talking about, it would
still work this way, but when one creates a new module, only the
"module class" would be inserted.  Any classes inside the module would
not be inserted into the global namespace and would therefor not be
visible globally.

The "module class" could chose to behave completely as a normal class,
i.e. the messages it exports/answers do their work by using the
module's internal classes and objects, as well as global classes and
other modules.  An example of this might be a Seaside application
which simply/responds to #renderOn: but internally has a complex
series of class/objects determine the behavior.  From the point of
view of Seaside there is just one class that receives the render
request.  This is actually what we have right now, but the difference
is that today every class even remotely involved in the application is
visible everywhere, despite being essentially "private" to the
application.

The "module class" could also chose to behave as a "namespace", simply
restricting access to its internal classes.  But the most common
behavior would likely be a hybrid between these two possibilities.
That is, often you would send a message to this visible "module class"
and it would behave as though it were a normal class.  Other times you
might send a message and the return value would be an instance of one
of the modules internal classes (think, a regular instance creation
method like Point>>x:y: that just happens to return an initialized
instance from a class inside the module).

Now, the question of course comes up of how such a system would look,
be implemented, etc., etc. and I haven't really thought about that
part yet.  I'm sure I'm not the first person to think of such a
system, so my question is: what systems do you all know about that
sound like what I have described?

Thanks,
Jason



More information about the Squeak-dev mailing list