A Proposal for Project Layers

Dan Ingalls Dan.Ingalls at disney.com
Mon Oct 11 01:21:13 UTC 1999


Folks -

I said I would summarize what we're up to with project and name spaces, so here it is.  I have been meditating for a few months on how to make a few simple changes, and get most of the benefits of a package system for Squeak.  The goal is not to rival Gemstone and other systems for industrial-strength development and distribution of applications.  The goal is to do something simple, along the lines of wiki-wiki, that enables the sharing of software and active-object content, and that extends the bounds of Squeak over the internet within the limitations of a simple model.

At the same time, we freely admit to having less experience than other squeakers with name spaces and other mechanisms out in the industry for packaging and exporting objects and applications for object-oriented environments like Squeak.

This is something we're going to do anyway, so please don't try to convince us it's not worth doing.  However I am hoping that some of you will read through this proposal, and give us some early warning about problems we are likely to encounter, and possibly make suggestions about how a little change here or there might make things simpler, more general, or more harmonious with other models and other software in general on the internet.

Project Layers
--------------------
0.  You have probably read about our experiment hooking up projects to image segments.  [See the recent message, "ImageSegments for real", 10/6/99].  Think of it simply as hooking up an object storage mechanism to projects in a way that lets them be passed from one Squeak to another, and that can also be used to swap them in and out of memory to save space.

The proposal is to extend this capability in several ways...

1.  Allow the Smalltalk global dictionary to be extended in a hierarchy.  This means that SystemDictionary would gain an added instance variable called 'global' or 'parent' or the like.  The methods for at:, at:put:, and others would be extended so that if a key were not found, and the parent were not nil, then access would be attempted at the next higher level in the obvious manner.

2.  Allow a class to specify its nameSpace.  For classes as we know them, this would simply refer to the same old top-level system dictionary.  For a class that is part of a package, this would point to a descendant of the top-level dictionary in which that class and other related classes and global variables would be defined.  I think this may not even be necessary.

3.  Allow a project to establish its own binding for the Smalltalk global dictionary.  For projects as we know them, this would simply point to the same old global systemDictionary.  However if a project were declared to be a new layer, then any references to Smalltalk or other attempts to look up global variables in that project would be addressed to the local system dictionary of that project.

Get the picture?

4.  Browsers and SystemOrganizers would be extended to handle all of this gracefully, of course.  I haven't decided whether this means putting a new filter into the browser that sets the layer level, or whether the system category list would be partitioned by layer, or something else.  Suggestions?

5.  The mechanism of isolated projects would be adapted to serve this layering in the following way.  Additions, removals or redefinitions of methods in classes defined outside the project would be recorded as local to the project.  Upon entry to the project, they would be cast into the rapid-revert mechanism of isolated projects to allow easy recovery from errors, and to assure that the outer system is relatively protected from changes made inside the project.

6.  Stores into global variables (and this includes class variables) would be monitored for undoability.  I am thinking that stores into Smalltalk would be forbidden except at the level of the current layer.

7.  The current changes file would be layer-related.  Thus all changes at the normal base layer of Squeak would use the normal .changes file.  However, a change in a sub-project layer would be logged to a separate changes file for that layer.  The condenseChanges operation would only affect the changes file for the current layer.

8.  Essentially all of this should work without qualified variable names.  But in various situations, we might want to be able to say, eg, "ThingLab.Line" or "Global.Rectangle", and this would certainly be useful in, eg, mixed-level browsers such as a messageList showing all senders of some message.
-----------------------

What would this enable?  Well, export and swapping of projects as we know them is already handled by (0).  The new capability, by layering global variables and therefore classes, and by associating the changes file with the layer, would allow code-heavy systems such as ThingLab or Prolog to be exported as segments, and similarly to be swapped in and out of a running Squeak.  This would also have immediate beneficial effects for the Squeak release itself.  For instance, all the Play-With-Me examples could be non-resident projects, and numerous large subsystems could be cast into layers.  It could actually be the beginning of a modular Squeak.

It is my inclination to stick to a hierarchy of layers, and to identify the layer hierarchy with the project hierarchy as well.  This is simple and intuitive, and lots of it is in place already.  But would it be an undesirable restriction?  Would we be happier for layers to be more of a mix-and-match kind of thing?  I don't know.  How similar or different is this from systems that you have worked with in the past?  What is your favorite example of what packages do for you, and do you think this would work as well?

One last thing:  It has to be simple, because it has to be working for OOPSLA  ;-).

	- Dan





More information about the Squeak-dev mailing list