Andrew,

[Re: Delta Modules]
> So, my question is: why do you consider DelatModules as being
> conceptually different from Modules at all?

A good way to think about DMs may be the following (which happens to be the
way how I think about them ;-)

When we do some work in Squeak we usually have two parts in it. One being
the "core" of our module, the classes and methods defined intrinsically. If
not for class Object, the module should be able to run "within itself", that
is being a self-contained entity (plus the modules and classes it imports).

Then the mess starts. It starts because we need to interface our module with
the existing system. This usually includes adding methods to various places,
methods that - given the absence of the things we modify - don't even need
to be there. As an example, if there wouldn't be a file list or a world menu
in Squeak we'd never have the need to extend it to be able to load some file
that our module handles. If there were no other classes besides the ones
defined in our module, we would never have the need to extend Object with
one of those common "isMumble" methods. Etc. etc. etc.

Thus, interfacing with the environment is where all the mess starts and
where it ends. Delta Modules do nothing but encapsulate this uglyness in a
nice way. Delta Modules say "okay, for making this module work in a given
environment I need some modification of x or y in a different module" and
that is conceptually very different from defining a set of useful classes
which - given the absence of the environment - could perfectly well stand on
their own.

Hope this helps,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf
> Of Andrew
> P. Black
> Sent: Wednesday, October 03, 2001 3:57 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [ENH][Modules] Delta Modules [was: Another version]
>
>
> Dear Henrik,
>
> It is good that you are improving the presentation on the Wiki,
> because that is a better place to find answers that the mail archive.
> (But it does take so much longer to edit the Wiki ... lucky I have
> cable Internet in my flat)
>
> Your changes do clarify the meaning of what is there quite a bit, so
> thank you for that.  But they do not answer my questions, only
> confirm that I do really still have those questions.  So, let me try
> rephrasing my questions so it is clearer what I am asking.
>
> Question the first:
>
> 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?
>
> Question the second:
>
> DeltaModules are a kind of Module[2].  They are distinguished from
> base modules by being defined by difference.  So, for example,
> StringWithUrlOps might be defined as being the same as String_V1.2
> with the addition of a specific set of Url manipulation methods.  But
> the DeltaModule does not do this as a set of changes, but rather as a
> definition of the final state.  Right so far?
> So, my question is: why do you consider DelatModules as being
> conceptually different from Modules at all?  Why do they have
> different properties, just because they happen to have a different
> representation?  After all, v2.3 of a text document is still a text
> document, regardless of whether it is defined by deltas from version
> v2.2 or by giving the full text.  In OO terms, the representation
> (whether by delta or by absolute) is hidden, only the protocol is
> important.  Why do DeltaModules and Module not have identical
> protocols?  Why are DeltaModules and regular Modules not just tow
> implementation classes with the same interface?
>
> References:
>
> [1] http://minnow.cc.gatech.edu/squeak/2071
>
> [2] http://minnow.cc.gatech.edu/squeak/2063
>
> >Andrew P. Black wrote:
> >
> >>  I was reading about the concept of "Delta Modules" on the
> >  > Swiki (at http://minnow.cc.gatech.edu/squeak/2063).
> >...
> >
> >>  Finally, what is the motivation for introducing
> DeltaModules in the
> >>  first place?
> >
> >Andrew,
> >
> >To try to answer these questions, I fleshed out that page,
> this should
> >hopefully be useful to you.
> >
> >http://minnow.cc.gatech.edu/squeak/2063
> >
> >>  If these advantages make the separation of loading from activation
> >>  and unloading from deactivation worthwhile, then shouldn't we make
> >>  the same separation for Modules themselves, not just for
> DeltaModules.
> >
> >I added a new page for this.
> >
> >"What about conflicts between modules?"
> >
> >http://minnow.cc.gatech.edu/squeak/2071
>
> I don't see what conflict resolution has to do with my question at
> all.  But maybe you thought that I was asking a different question;
> sorry for being unclear.
>
> I don't understand your page about conflicts either, but I made a
> comment on the page.
>
> 	Andrew
>
>
>