Musings about modularity and programming in the large

Michael van der Gulik mikevdg at
Wed Jan 23 22:50:36 UTC 2008

There is code available on the 3.10 Package Universes that I'm currently
using to varying degrees of success.


On Jan 23, 2008 6:36 AM, Jason Johnson <jason.johnson.081 at> wrote:

> So no one knows of a system like this?  There's nothing new in our
> field since decades so I'm sure there are papers or an implementation
> out there, I just haven't found it yet.
> On Jan 20, 2008 5:30 PM, 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