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