Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote:
> It did mix the implementation aspect with how DMs would be used, in the
> manner of "here are some problems, and this is how DMs can address them".
> The implementation difference is not strictly linked to the uses I
> mentioned, but in practice there will be such a link: the convenience of the
> delta representation means that class extensions probably will be put in DMs
> 99% of the time, and so on. 
Please - lets nail this point down, because the abstractions are all
blurred in my head.
Do you mean that I'm *can* put extensions in Modules if I wish?
If modules and deltaModules ARE equivalent, except for DMs being defined
relatively, this means that modules can conflict, and thus it would be
useful to be able to load but not install those, too.

> The result of activating/installing a DM is equivalent to creating a
> new/different version of the base module by filing in all the contents as a
> regular Module. (I now think that de/activating a DM is a better term than
> un/installing it.) You aren't forced to use DMs for class extensions, but
> filing in five new methods is clearly more convenient than loading a new
> version of the whole module that contains String.
This is where I get confused, so I'll conjure a practical problem.

The RefactoringBrowser wants Behaviors to respond to parseTreeFor: by
parse themselves using the RBParser (defined in module RBModel). Well,
this means I need to put an extension on Behaviors. There are two issues
now - 
* Where do I put it? in the RBModel Module, as an extension of a class
not defined in it? or in a separate behavior extensions module? The
first is what I do now, and what seems natural to me. The second
requires a scheme for these things - the extension module would have to
depend on have the Behavior module as it's base, and depend on the
RBModel module, and be depended on by whoever wants to use this message
- sounds like a lot of work.

* When will this change conflict with another module? will it conflict
only when a logical conflict occurs (another installed module defines
#parseTreeFor:) or whenever another Behavior extension module is being
loaded, regardless of what it's modifying?

It sounds like DMs as defined will have the stricter conflict behavior,
simply because you cannot be at two versions of a module (the base
module) at the same time. This seems very restrictive, if I have two
applications modifying a base module in different, unrelated ways.

> Activating a DeltaModule does not modify its base module--it creates a new
> version of the base module, with the modifications installed. Being able to
> modify a module is a bad thing since different code packages should be able
> to specify a module by version and be able to rely on its contents. But this
> distinction is a technical detail.
I agree! Published means immutable.
 
> If two different loaded systems want to modify the same module (the same
> class/es), then you need to switch between the two module versions created
> by the modifications--you enter into the area of conflict resolution.
So maybe I'm wrong in my interpretation...
 
> Andrew P. Black wrote:
> 
> > I understand that "DeltaModules can be un/installed, but the
> > un/install operation has no meaning for regular Modules" [1].  My
> > question is: Why.  If un/install is such a good idea, why not have it
> > for all Modules, not just for DeltaModules?
> 
> The reason is that Modules are independent and self-contained, and therefore
> cannot be in conflict with each other. However, several packages may want to
> apply DMs to the same module, and then there is a use for being able to
> de/activate all but one of these DMs.
What is a package? Is this a Module, a DM, or a third concept? 
It sounds like something I need (Celeste should be able to extend
MIMEDocument, and Scamper should too. OTOH, if the changes don't
logically conflict, I want to have both loaded at once, and it sounds
like I won't be able to).
 
[big snip further subtle point]
I'm still very much confused about the basic definitions...

> Henrik