Ok, perhaps a long post but anyway - IMHO it's important that we have
this cleared up.

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> But you could have method definition and removal in a module without 
> needing the distinction between delta modules and modules.

But why mix those together? It will only mean that:
a) I can not make the assumption (as you can today) that a Module is
*stand alone* and can't possibly conflict with anything else.
b) A Module turns into some form of ChangeSet (recording of operations)
instead of a snapshot of classes.

> How do we do that with parcel, envy applications exactly like that. I 
> say I take the module 1.29a then I removed the method xxx
> and I version it again as 1.29b

Hep - that is different (I assume). 1.29b does not contain a *removal*
of a method. It simply does not contain the method you removed. Big
difference.

> For me the distinction between modules that are clean and delta that 
> are only methods has always been strange.

Eh, a DeltaModule does definitely NOT contain "only methods". Let me
repeat this one more time:
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.

So again, what are the nice properties of this scheme?

1. A Module is thus tremendously simple. It is just a bunch of classes.
No history, no additions/removals or anything - it is very much like a
category .st-fileout. It can't get simpler than that, and simplicity is
our friend.

2. A Module can't possibly conflict with another Module since it is in
it's own namespace. This is a very important aspect. You can load all
and any Modules into the image without any worry whatsoever, after all
it's only classes and simply filing in classes never hurt anybody
(unless the class initialization does dumb things, but that is another
story).

3. As we all know somewhere the "dirty business" must be taken care of,
otherwise all these Modules turn into isolated islands of no connection
at all and just sits there like dumb ducks. :-) And this is the job of
the DeltaModule. Think of it as a ChangeSet which can be reverted
(activated/deactivated) and that can only affect ONE Module. Since
DeltaModules carry all your changes in Modules that are not your own
they by definition contain the areas of your code that CAN conflict with
others.

So - the separation is very clear to me. When I write code everything I
write can be separated into two groups:

1. My own classes.
2. Changes in other peoples classes.

Voila! Modules and DeltaModules. Since I control my own classes I can
represent that code as a snapshot of the classes. But I don't control
other peoples code so those changes are best represented as *recorded
changes* to those classes.

Ok, now if you do not like DeltaModules - what do you propose instead?

You can't just say - just put it in the Modules, because then you are
simply moving the problem into the currently nice, clean and simple
Modules. And you can't just say "use ChangeSets" because they are not
reversible and if I am not mistaken have other weird problems... The
DeltaModules are meant to BE the ChangeSets of the future.

regards, Göran