Hi Göran

On Mon, 4 Feb 2002 goran.hultgren at bluefish.se wrote:
> 
> There is probably a good description of the Modules system on the Swiki,
> and even though I promised Stephane to write something up, I am not sure
> if I will be able to do that "in time". Anyway, without having looked at
> the latest of this stuff my perception of these things as of OOPSLA (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 lasses (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.
> 
> Well, over and out, perhaps someone got a bit wiser... :-)
> 

Yes, thank you for this short and well written explanation on
DeltaModules. I asked in another thread about DeltaModules and some hours
later I find an answer on the list. This is great!

I like the concept of DeltaModules. It is easy to grasp and seems to be
powerful (well we'll see in the future but it looks
promising). DeltaModules will allow me to build my Squeak application
which will be more easily maintainable and to keep in synch with the
upgrade stream. It will give me the possibility to change base classes for
my needs without loosing track. Up until now I avoided this as much as
possible.

Cheers
Hannes Hirzel