I think many issues were answered in my last mail. The rest is here.

Allen Wirfs-Brock wrote:

>> Have you got his code by the way? I can always give you an url with the
>> image we used at OOPSLA.

I haven't released anything since this should be in the official update
stream any day now. If it still isn't that means SqC is pounding on it,
among other things with Alan's 170MB demo image. I think this is a good
thing, especially since I haven't had any bug reports yet...

> Actually, I've been kind of avoiding using the code as a reference.
> Facilities like this should be explained and understandable without
> reference to source code.  Otherwise it is impossible to separate the
> specification from the implementation details.

Another danger is that parts are unfinished or preliminary, and I may not
have explicitly noted that in all places. But then again looking at the code
can clarify many things.

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

>> BUT... you can also "link" modules as an external module - didn't I
>> write that? Yes I did. But perhaps it wasn't clear. Or perhaps I am dead
>> wrong. Henrik, correct me here but wasn't the idea that if a module
>> needs to reuse an already existant module placed somewhere else
>> completely in the module tree it just references it as an external
>> module? I think so.
> 
> Perhaps, I guess this is where some of the complexity leads to confusion.
> Is there really the need for both external modules and submodules and
> module parameters.  Are their usages truly orthogonal? Will user's know
> when to choose one over the other? Couldn't this be simplified?
> 
> Regardless, you have clarified one thing for me.  Apparently, there is a
> module definition tree (with parent back pointers) and a module usage
> (dependence) graph.

Yes, the dependence/usage graph is independent of the naming/conflict
avoidance scheme. And sub/parent relations only have to do with the location
and thus name (path) of modules, by putting every module in exactly one
place. This was chosen to have a simple system for avoiding name conflicts
that wasn't based on long strings of random characters and digits.

As far as module parameters go, one can just ignore them until one needs
them, and I think we rarely will. In fact I'm still looking for an example
use for testing the implementation (which is unfinished still). But some
people wanted them badly and I knew a simple way of getting this.

> Here's a sketch of what I think of as a prototypical "module" when I
> consider things like this:
> 
> module "FooImplementation"
> extends class Object with method isFoo
> implements class Foo with assorted methods
> references class Bar (defined in another module)
> 
> To me, this is a nice self-contained unit.  Why would I want to be thinking
> about changing the definition of the module that defines Object.  It's not
> necessary in order to implement the above.  It also would have a broader
> effect then I intend.  If Object's module now essentially imports Bar (or
> Bar's module) as a neighbor then presumably this has the side-effect that
> its other submodules of Object's module could also reference Bar.  (As a
> side point, I also don't really want to think about which module implements
> Bar)

No, this is not a self-contained unit at all, since you modify the contents
of another module--the one holding the class Object. An essential principle
of modularity (indeed, being self-contained/independent) is that modules
should not be able to affect each other's insides, and this is what you do
by changing the implementation of Object from another module.

Now the definition of Module A (holding Object) may be potentially spread
over every module in the system. Clearly this violates the essence of
modularity--but this is not just bad in principle, it also breaks the
algorithm for dependency and conflict resolution. If module B has A as a
prerequisite, it isn't enough to verify that A is loaded, you now have to
potentially check every other module in the system to be sure that the
module A that is loaded is indeed the module A that B thinks it uses.

This is a Bad Thing."Modules" that may modify other "modules" are not
Modules in the computer science sense of the term. They are merely code
packages or some such. Yes, I really think this flaw is that fundamental.
And I will repeat this till everyone agrees ;-)  And this is why there are
DeltaModules.

> As I mentioned above, it appears to me that there are really two overlayed
> structures.  A definitional tree and a dependency graph.

Right, a "naming" tree and a dependency graph.

> So what if I need to define a module like this:
> 
> module "FooImplementation2"
> extends class Object with method isFoo
> extends class Collection with method asFoo
> implements class Foo with assorted methods
> references class Bar (defined in another module)
> 
> and Object and Collection are defined in two different modules (note I
> didn't use the term "module revision" , at this level of abstraction I
> don't really care about specific revisions).  It sounds like this extension
> would be impossible to define because it would be a delta module that would
> require two parents.

But parents are only related to naming.

You would have 

Module Foo2
which defines 
    - a DeltaModule on A (defining class Object)
        - which extends A Object with isFoo
    - a DeltaModule on B (defining class Collection)
        - which extends B Collection with isFoo
    - module C (defining Bar) as an externalModule (that it uses/depends on)
and contains
    - the implementation of Foo
> I think what you really mean, is that you can start with just
> BazImplementation 1.0 and instead of creating BazImplementation 2.0 to add
> a new method you can create BazImplemention 1.1 and  DeltaBaz 12.0.

I think Göran meant this too.

> Thanks for the interaction. I like it.
> 
> Allen

Me too, I appreciate that the logic of the system is subjected to "tests"
such as this.

Henrik