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