So do not see why we need modules and just keep deltamodules, and 
rename it delta.
This distinction is ad-hoc.
But if you believe it is worth the conceptual mess go for it. I imagine 
me teaching it....dramatic.
Stef

On mercredi, octobre 16, 2002, at 06:34  pm, goran.hultgren at bluefish.se 
wrote:

> 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
>
>
Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes