[ENH][Modules] Delta Modules [was: Another version]

ducasse stephane ducasse at iam.unibe.ch
Thu Oct 4 05:39:34 UTC 2001


Hi andreas


>> 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.


Have you worked with VW and/or Envy?
in envy this is called class extension, in envy they cannot hide pre
existing method nor change the class definition, while in VW with Parcel
you can hide 9and get it back on unload) a method and may be change the
class definition I have to check,

> 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.

This is not that different, you only do not define a class. But DM should be
unloaded when the module they refer to unload. I do not really see why there
is a difference between the two. This is just the way program are perceived
and this is fun to see that in a world like Smalltalk where normally we can
add method anywhere we start to do a conceptual distinction between class
and method and method attached to other classes. A module could be just a
list of declaration (method, global, class,..... and you do not need to know
what is DM or Module) as soon as you know what belongs to a module and you
can load it and unload it.

Another question

I have mod1 with extensions (DM1) = String>>asUrl

can I see String>>asUrl from mod2 if there are not relations between the
two?

I have the intuition that I should only see asUrl from a module only if this
module depends from mod1.

What is your point of view on that?





> 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
>> 
>> 
>> 
> 
> 
> 





More information about the Squeak-dev mailing list