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

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Oct 23 08:45:59 UTC 2001


Hi again!

Now I have Henrik's image up on my laptop and can TRY to clarify a few
things more. This time I am snipping. And beware - wobbly "truths"
ahead... I rest assured that Henrik might correct me. ;-)

goran.hultgren at bluefish.se wrote:
[MEGASNIP]
> > >But the very purpose of modularity is to separate a system into smaller,
> > >independent, self-contained pieces, whose definitions are not entangled in
> > >each other. Modules really should not be allowed to modify the contents of
> > >other modules. Allowing this would go against the very idea of
> > >modularity--it is really a contradition in terms, more or less. It is the
> > >same violation as if an object would be allowed to directly alter the
> > >innards of another object, it breaks encapsulation.
> > 
> > So are you saying that Modules cannot modify the contents of other 
> > Modules, or that they can?  I'm confused again.  Is a Delta Module a 
> > Module, or not?  It sure sounded like a module up until now.
> 
> Ok. Lets see know. A Module can only contain classes (well, actually
> globals but let's keep it simple). A "loose method" can only be kept in
> a deltamodule.

Ok, let's get our hands dirty here and aim for extreme clarity:

Object subclass: #Module
  instanceVariableNames: 'version parentModule neighborModules
definedNames exportedNames repository'
 ...

And from the class comment:

"All "the neighbormodules" --external modules, submodules, module
parameters, delta modules-- are held in an OrderedCollection to strictly
define the order of lookup of names outside this module.
..."

Then we actually have:

Module subclass: #DeltaModule
   instanceVariableNames: 'baseModule isActive'
  ...


A few notes on this:

- External module = a reference to a module "outside of this module
tree". This could also be named usedModules (Henrik and I discussed
different names for that) and you could think of it as "prerequisites"
too, BUT it does not have anything to do with loading order.

- Submodule = Another module that is one of my children. Consider it a
"part of me". Especially note that a submodule of "me" has me as it's
parent. This is in contrast to the external modules whose parent is
someone else completely.

- Module parameter = Well, perhaps it sounds better if we call these
"parameter module" instead. It is an advanced feature that means that
the module shas a "valueholder" instead of a reference to a concrete
module. We then have to specify a concrete module as a value when we
load (or perhaps activate?) the module in question. An example would be
to make stuff "pluggable" so that for example you could bind another
"Transcript" than the standard one etc.

- Delta module = Yes, we have discussed these in length. When going home
on the train last night I saw them even more clearly than before. Let me
explain:

If we build a module with everything in it (classes and loose methods
end tutti) in a big pile we have a problem. The classes are self
contained, they are what they are and do not need any more information
to be "complete". But the loose methods (read class extensions) need a
"home". Ok, so we have to say what class they should go into. But then
we are still not clearly defined because - what version of that class
are we referring to? We need to say "this loose method should go into
class Object version 1.34" to clearly define things. So our "loose
changes" to classes outside of our own module needs to be complemented
with information about the version of those classes that they refer to,
right? Aha! This is exactly what the Delta modules do! They group our
"loose changes" that should be applied to classes in other modules and
complement them with information about which specific module they should
be applied to.

Note that a Delta module could as easily be represented as a full
snapshot of that modified module - but that would be very inefficient. I
can also see an advantage in having it in "diff" form because then it
should be easier to do conflict detection.

- One thing that might confuse people is that when Henrik (and I) says
"module" he means an exact version of a bunch of code. This means that
"Morphic 1.23" is ONE module and "Morphic 1.24" is ANOTHER module. In
ordinary speech we sometimes talk about "the module Morphic" talking
about all/any version of that stuff. This is a naming problem and
perhaps there is a better word for "Module" that we should use... A
deltamodule is always in reference to a specific module, for example
"Morphic 1.23". So when a module has been "published" it should never
ever change content of course.

- A Deltamodule inherits from Module and this could perhaps be
refactored with a common baseclass as is common in the Composite pattern
but I haven't looked into that issue. One fact though: Looking at the
code a Deltamodule CAN NOT have neighborModules. Those methods are
overridden. So, a Delta module can only be a leaf in the Module tree.
Henrik, what about applying the Composite pattern here? Or are there
other considerations?

- Looking at all this it should be clear that the Module tree is
primarily a tree but the external modules and the module parameters
create references to modules "across" the tree so it becomes a graph
instead. But remember that a module always knows only ONE parent so in
essence it is still a tree with "foreign crossreferences".

[SNIP]
> > >Since DMs are defined as differences in relation to a base module, per this
> > >definition (and for superseding change sets) they strictly ought to be able
> > >to define any possible differences in a module, however some changes are
> > >harder to support than others. Still, adding new classes should definitely
> > >be possible, and it is easy to support (DMs being Modules, I think they
> > >already do). But this would probably be used when DMs are used in the role
> > >of change sets--a package will rarely need new classes to be added to other
> > >modules.
> > 
> > So DeltaModules can define globals and whole classes too?  Was I 
> > wrong again?  I'm frustrated that after all of this discussion, I 
> > still cannot seem to get a three line summary of what things go in 
> > which kind of Module.
> 
> Eh, well since a Deltamodule defines a difference between two modules it
> should be able to contain a whole new class. But you would probably
> rather seldomly have one Module add classes to another module so it will
> probably be a rare case.
> 
> The threeliner (well, we can all try to revise this one so that it gets
> really good):
> 
> A Module contains globals including classes.
> A Deltamodule contains all possible differences between two Modules.
> (changed methods, added methods, added classes, removed methods or
> classes etc.)
> A Module can contain other Modules and Deltamodules creating a tree.
> 
> I do not think a Deltamodule can contain other submodules so I think
> Deltamodules can only constitute leafs in the tree... Darn, don't have
> the code available, I can check tomorrow.

Ok, so revising it a bit further (leaving out module parameters):

- A Module contains global definitions including classes and can contain
other modules and Delta modules creating a tree.

- A Delta module can only be a leaf in the module tree and defines the
difference between two Modules. (changed methods, added methods, added
classes, removed methods or
 classes etc.)

- A Module references so called external modules (used modules) outside
of it's subtree. This is primarily for name lookup and making sure we
have the right modules activated in order for the module to be able to
run.


Obviously the Delta modules are the tricky part - but personally I just
view them as a "diff" between two modules. I do have a question to
Henrik though - the deltamodule refers to the baseModule that is applies
to but it doesn't refer to the resulting module when it has been
applied. Ok, I admin that the last sentence sounded strange, but let me
put it like this: When Delta module Z has been applied to "Morphic 1.23"
I can't really say if the result is "Morphic 1.24" or whatever? The
source is defined but the target is not. So... I am not even sure if
that is a problem, but perhaps it can be? When it comes to conflict
detection I mean. Whatever...

I really SHOULD read the Swiki stuff that Henrik has put up there... :-)

Regarding name lookup, I have no clear image right now but I guess that
a Module just uses the ordered collection of external modules to bind an
external reference to a class/global. So... that means that name lookup
is somewhat orthogonal to the Module tree. More or less like in Java
(import com.sun.banana.*; etc) or any other language, I guess?

Regarding BasicModule, I think that it doesn't exist as a special case
in the code. I guess "it is just a Module with no Deltamodules within
it's subtree".

Regarding PackageModule, it was mentioned by Henrik as something not
needed. I know nothing more on that subject and haven't followed those
postings.

regards, Göran




More information about the Squeak-dev mailing list