Dan Ingalls wrote:

> The problem comes when several packages make simultaneous changes to the base system. In this case it becomes overly complex to manage assertion and retraction. You can deal with it stylistically (don't change the base classes (or almost never)) and/or administratively (declare such changes and warn of any conflicts).
>
> If I had to call this right now, I would prohibit packages from making any changes outside their own scope but I would allow projects to have attached changes that would be asserted and retracted according to the current isolated projects mechanism.
>
> I could imagine a hybrid form of use evolving, where someone writes a big package like T-gen as a project with changes to the base system, and then clients access it through a protocol that asserts those changes for the duration of that access, but this just increases the use of something I don't really like.
>
> Can anyone suggest a better approach to this?
>
> - Dan

This is, at least in principle, what my Collage system tries to solve. You might look at the Swiki for more information, and I think I posted this in earlier Squeak mail, but here's a short summary again:

In Collage, a Smalltalk system consists of stacked layers, where each layers can have definitions, removals and renamings for the following things:

   * Classes (naturally) within namespaces.
   * Inst vars and class inst vars of classes within or below this layer
   * Methods and class methods of classes within or below this layer
   * Static variables within a namespace (a class also is a namespace in this context)
   * Namespaces within namespaces
   * Pool refs (references to namespaces) of classes within or below this layer

Layers can contain a stack of sublayers which can be though of as patches to the original layer. Removals in these layers (and in global layers, too) can either completely remove the definition of something, or they can remove an override, making the original definition visible again.
Definitions and removals are concepts that you will find in almost any change set. Renaming is something that's more elaborate. In essence, it allows you to rename all statically bound things (everything except methods), making the new name visible in this and all upper layers.

A stack of such layers, together with the information which patch level is active in each layer, is a Collage. I named it like that because I compare it to the 'Jigsaw Puzzle' approach of ENVY: all pieces in ENVY must fit together, there must not be an overlap.
In contrast, overlapping in Collage is part of the concept: it allows you to cleanly make major system changes without ever touching the original layer in which the system was defined. This is certainly needed in an environment where code from separate sources will be incorporated in a system, and you want to be able to load newer versions of that code without redoing your changes to
it over and over again.

The Collage approach is fully compatible with the traditional sequential file-in approach, but you have the ability of removing or rearranging layers at any time.
I think the Project isolation stuff could be done by having a separate Collage per project. There might be a mechanism to specify which parts should be shared with other projects (such as the base system) and which parts should not be shared, either because they are private or because that project requires a specific version of a layer to function correctly.

I have some of the mechanism working already, but currently there's not enough time to continue on it.
Next year, around April to June, I will have a 3-month sabbatical which I want to use to fully implement this thing. Other parts which I did not yet start include a mirroring server network for sharing Collage layers, and a meta-information structure that captures compatibility information, bug and bug fix notices, configuration info etc.

In my opinion, this approach provides both stability and flexibility.

Hans-Martin