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

Andrew P. Black black at iam.unibe.ch
Fri Oct 26 16:45:48 UTC 2001


Folks:

I don't want to enter into this discussion in a major way, but I also 
don't want to be silent lest it appear that I am ignoring you.

I have spent significant time reading the postings in this thread 
this week.   And some things do seem to require a few comments from 
me.

First, I really must apologize if I have upset anyone by my mail 
here.  I think that at least Andreas was a bit impatient with me.  I 
didn't mean to annoy anyone; please accept my apologies if I did.

I care about Squeak modules because I believe that Squeak is the best 
tool that I have right now.  The reason that it is the best is that 
Andreas and many others have worked very hard on it.  My 
contributions are tiny.   I appreciate what you are doing.  And I 
accept that you probably know a lot more about the domain than I do. 
Andreas' question about the filled polygons and the delauney 
triangulations made this point: no, I would not come up with that 
solution, because I haven't a clue what a delauney triangulation is.

The place that I was starting from is that not only should there be a 
user story  -- and I liked the story that Andreas took the time to 
write -- but that should be consistent and complete.  So when I see 
something from Henrik and something from Andreas that appear to 
conflict, it means either that the story need to be refined, or that 
I have not yet understood.

Of course, I accept the position that it would be a mistake to spend 
a lot of time writing documentation before implementation starts, 
knowing that some of the concepts would change.  That was why I made 
the XP analogy -- not because I belive that XP is the only good way 
to do development, but because it is the way of developing without 
up-front design with which I was most comfortable.

>One place in the discussion where "the other shoe dropped" for me 
>was when someone said that as I write code in my Squeak environment, 
>the _system_ notices that I'm adding a method to a class that is not 
>in my module, and therefore creates a DeltaModule to hold it.  This 
>makes sense to me; this is why DeltaModules are more than a 
>convention: they are enforced by the tools!  I hadn't realized 
>before that this was how it worked; I had assumed that the 
>programmer has to do the right thing "by hand".  This was a big 
>"aha" for me.

Part of me can't wait to get the release so that I can try this all 
out, but I also really appreciate Alan's comments on wanting to avoid 
prematurely making assumptions based on early code.   Alan also made 
the really important point that the in-memory representation of a 
loaded module is not what matters: it is the "abstract syntax" of the 
external representation.   So, for example, on the  issue of whether 
a submodule "knows" about its super module:  this question needs to 
be answered with respect to the abstraction of module, not the 
in-memory representation.  The representation might build a 
(collection of) references to supermodules as an optimization, 
without compromising reuse, but the abstraction should surely not 
have any such reference.

The one inconsistency that still troubles me, however, is the one 
that started this thread.  Henrik insists that a module must be 
"independent of all others".  This seems to be a cornerstone for him:

At 14:55 +0200 2001.10.25, Henrik Gedenryd wrote:
>  > There has been a lot of discussion (and little agreement??) on this list
>>  about what we mean by a "module". Cutting through the nuisances I suspect
>>  that most people could accept the following: A module is an *atomic* unit
>>  of functionality (code, objects, whatever) with an independent existence
>>  that can be incorporated into a program (image, whatever).  The atomisity
>>  aspect is very important.  If loading a module, the normal expectation is
>>  that you get the whole thing.
>
>I would agree, if by "independent existence" or otherwise you mean that each
>module should be independent of all others. This is why I've been surprised
>and bewildered when people have suggested that modules don't always have
>their own namespaces, or even that modules and namespaces are orthogonal.

I can reconcile this with the need to use code from other modules, 
buy saying that that those other modules must either be parameters, 
or must be "imported". That is, an explicit dependency is set up 
saying that WebBrowser module uses HTML module, or whatever.

For this reason, Henrick says that

>  module "FooImplementation"
>  extends class Object with method isFoo

is not a self-contained unit at all, since it modifies the contents 
of another module, the--the one holding the class Object.

Hence the extensions to Object cannot be a module, right?

Hence, they have to be something else, because we all know that we 
need to do this kind of thing sometimes.

That something else is a DeltaModule!

And here is the part where I'm still confused: this seems to imply 
that DelatModules _are not modules_.  Because they do what Modules 
cannot and must not be allowed to do, that is, to modify some other 
module.

So, DeltaModule is a bad name.  But, most importantly, DeltaModules 
must not be allowed inside modules, because then the Module does what 
it is not permitted to do.

But we _do_ have to create some kind of packaging mechanism for whole 
applications, which typically require BOTH new modules and changes to 
existing modules.  Which was why I suggested PackageModule.

I think that the current situation is that

	(1)  Modules that contain DelatModules can change other 
modules, but that
	(2)  Modules that do not contain DeltaModules must be 
independent entities that depend only on their parameters and imports.

I can live with that, but it does not seem to be a very clean 
foundation on which to rest such an important cornerstone.

I'm sorry to belabour this, but I make my living from explaining 
ideas to others, and I know for experience that names that don't mean 
what they appear to mean are a big inhibitor to understanding.  And 
exceptions to rules are another.  I've been struggling to learn about 
Envy this week, and the naming that they adopt certainly doesn't help 
either.

Well, that's far more than I intended to write -- time to quit for 
this evening.  Thanks again for paying so much attention.

And finally -- there is no need to CC me on this thread; I get the 
whole Squeak list, and the original and the cc both get filtered into 
the same "Modular Squeak" folder.  So I just see it all twice.

	Andrew





More information about the Squeak-dev mailing list