Andrew,

This reply got stuck in my inbox--my ISP was down and then I went to OOPSLA
where there was no easy uplink at Camp Small Talk (as it was called) as I
had thought. Anyway, now the replies from Göran and Andreas have made most
of it redundant. Here is what's left of it:

>> filing in five new methods is clearly more convenient than loading a new
>> version of the whole module that contains String.
> 
> If filing-in is the mechanism for loading functionality, that is
> certainly true.  In VisualWorks, of course, they load something like
> image segments, and the user can't see the pause.

There are other obvious advantages to the delta/diff format. I think a
developer would rather manage the five methods he changed, and thus needs to
care about, than have to manage all the rest too, and have to remember what
the changed ones are, Etc.

> I think that you are saying that Regular modules can _only_ define
> globals, whole classes, and DelatModules, and that additions and
> deletions to classes can only appear in DeltaModules, either nested
> within a Module or not.  Is that right?

Yes.

> So DeltaModules can define globals and whole classes too?  Was I
> wrong again?  

No, in fact this is perfectly consistent with what you just wrote:

> additions and 
> deletions to classes can only appear in DeltaModules

- Modules can contain global definitions (and classes are just one kind of
globals), and Modules may be composed with other modules.

- DeltaModules are defined in relation to a base module, and should be able
to hold any kind of changes wrt to it: I.e. add, delete or modify globals
(which again include classes), or add, delete, or modify what other modules
it is composed with.

As you see, the basic Module is quite simple, and complications are held in
DeltaModules.

For a simple analogy of the difference, think of Modules as .st files, and
DMs as .cs files (change sets). However remember that it is an analogy,
don't take it literally.

> (1) defining new stuff (we do this in a regular module)
> (2) changing old stuff (we do this in a DeltaModule)
> (3) packaging up a subsystem for distribution, which will
> usually require some of (1) and some of (2).
> 
> We could do (3) with a RegularModule, but that would destroy the
> purity of RegularModules.  We could do (3) with a DeltaModule,  but
> that would destroy the purity of DeltaModules.

These are all very well put. Think of the principles in the last paragraph
as structured programming vs. spaghetti code. Especially doing (3) with a
RegularModule would go against the very idea of modularity.

> We could  forget the
> idea of having different kinds of module, and instead have a tool
> that tells us what a module would do when loaded.  (My suggestion
> above.)  But if we reject all of these alternatives, then I think the
> consequence is that we need a third kind of module, the
> PackageModule, that just does Packaging, and nothing else.

I insist that a module modifying the innards of other modules breaks the
very principles of modularity, i.e. each being separate and isolated from
others.

For the same reason, such modifications would make conflict resolution and
"safe" loading impossible (or at least very complicated and ugly). The
strict separation of modules from each other is what makes safe loading and
conflict resolution possible and even conceptually simple.

For the sake of not modifying other modules, I now think 2 is better
described as

 (2) creating new versions of old stuff (we do this with a DeltaModule)

--I mentioned it before, but it is a technical detail.

Henrik