Ok, perhaps a long post but anyway - IMHO it's important that we have this cleared up.
Stephane Ducasse ducasse@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