Musings about modularity and programming in the large

Laurence Rozier laurence.rozier at
Wed Jan 23 13:38:01 UTC 2008

You may find ideas in Naiad <>, the module
system for Spoon <>.

On Jan 20, 2008 11:30 AM, Jason Johnson <jason.johnson.081 at> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Squeak-dev mailing list