DeltaModules (discontinued)
Last updated at 2:37 pm UTC on 16 January 2006
DeltaModule
The main reason why DeltaModules were added is that by this small introduction you can add a number of desirable features with a small and conceptually simple extension. (Strictly, the original reason was to allow conflict resolution, in the manner of SCAN layers.)
Defined as difference from a base module
- It is relative to another module (a specific version of it), hence Delta.
It should not record the changes, but the final state, it just represents the final state in a delta-format for efficiency.
Hence, it still provides an exact definition of a module but as relative to another module (the base module).
De/activating
- When loaded into the image, the DeltaModule can be active or not.
Ie. its differences wrt the base may be installed into the base module or not.
- De/activation can be done atomically (like isolatedProjects), and separated from code loading.
Subsuming ChangeSets
With these capabilities, DeltaModules can take the role of ChangeSets, while avoiding (some of) their weaknesses.
- Atomic de/activation means that you shouldn't need to worry about the order of the contents, as you so often have to with change sets, as long as the final result of installing a module and its submodules is consistent. Hopefully you will never need to hand-edit a file again!
- You also gain the ability to unload them, which you can't do with change sets. This is done after having deactivated them (atomically), no need to worry about inconsistent states during unloading.
- Since activation is separate from loading, if loading a file fails halfway through, nothing bad has happened to the image since the loaded contents haven't been activated yet.
Working with code that is not activated
DeltaModules (and regular Modules) would subsume the Package Browser (FileContentsBrowser), as a DM can be read into the image, edited, etc. without being active, the usual tools should be able to handle this (perhaps some Package Browser functionality may need to be moved into the regular Browser).
Downstream modifications
Deltas are meant to be used for holding downstream modifications to core classes, a k a external methods (think String>>asUrl or Object>>isDraggableMorph). A module that requires changes to other parts of the system would simply hold these in DeltaModules, which are then handled much like any other modules.
Conflicts and dependencies
Since they are a kind of module, they can be naturally handled as part of dealing with conflict resolution, dependency and version management, repositories, and so on, since all of these only need to deal with one kind of entity–the Module.
For instance, this gives you an ability to define dependencies and conflicts between "ChangeSets"–ie. DeltaModules.
De/activation also yields the ability to have conflicting packages in the image at the same time, and switching between them by deactivating the conflicting parts. Thus, a form of “layers” for handling conflicts.
(hg)
An email to the Squeak list illustrates the use of DeltaModules:
Short module/delta module intro! Re: A Tool for managing modules
From: goran.hultgren@bluefish.se
Date: Mon, 4 Feb 2002 09:43:15 +0100
... Anyway, without having looked at the latest of this stuff my perception of these things as of OOPSLA / Splash (I may be simplifying to get the points through):
Modules can be viewed as standalone collections of classes. They live in a namespace of their own and if they reference (references them, actually it's about globals in general, not only classes of course) other classe in other modules, those modules become so called "external modules" to the module. It's more or less like an "import" I guess. So a module "depends" on other modules in this way.
So far so good - it is quite logical that a module has a namespace of it's own, it also seems quite logical that it needs to, in order to be a real module - otherwise it would be able to clash with other classes having the same names in other modules. Now it only needs to make sure that the "external modules" don't have clashing classes (globals).
The ideas that a module only contains standalone classes (and no loose class extensions, see below) they are by definition loadable without conflict. It's just a bunch of classes that can't possible affect anything.
Ok, here comes the tricky - but I would also like to say - the neat thing: a DeltaModule
A delta module represents the changes that a module "needs to apply" to other modules in order to "be happy". The typical example is adding a method to a class in another module. Since a "pure" module can only contain "standalone classes" it will have to have delta modules (as children) for this.
A single delta module captures all changes that one module wants to apply to a single other module. So if our module wants to add two methods to two different classes in ONE other module, we get ONE delta module. But if those methods where to be placed in classes from TWO other modules we would get two delta modules - one for each other module that we need to apply changes to.
So if I find a module with 33 delta modules in it I get scared. :-) I can also tell that this module depends on 33 other modules in a non trivial way (trivial being a simple client of those other modules). If it had 3 delta modules I would be happier, and if it had none I would be real happy.
One more quickie definition from Goran:
A DeltaModule is more or less like a ChangeSet. And as you know this means that:
1. It can contain loose method additions/removals.
2. It can contain class definition changes like variable
additions/removals, superclass changes etc.
3. It can contain complete additional classes.
4. In fact it can contain any conceivable change to a Module.
(the above might not be implemented yet, but this is the plan/design)
The whole point of the DeltaModule is that it contains all changes you would like to do to another Module that is not yours in order to make your Module happy. So think of it as a ChangeSet with the restriction that it can only change one Module. And then add the very important aspect of reversability. A DeltaModule is activated and deactivated - when it is activated its changes are applied and when it is deactivated the changes are removed.
