> Stephen Pair wrote:
> 
> > In looking at the Module code, it seems that there is some 
> confusion 
> > over the nature of the Module hierarchy.  In certain 
> circumstances, it 
> > seems that the hierarchy implies more than just a naming mechanism 
> > (i.e. if you unload a module, it automatically unloads the 
> submodules 
> > by default).
> > 
> > I think I'm of the opinion that the purpose of hierarchy should be 
> > strictly confined to naming.  There should be no other relationship 
> > between modules and submodules implied by the name hierarchy 
> > whatsoever.
> 
> > In fact, it would probably not be useful to think in
> > terms of modules and sub-modules at all.  But rather, they are all 
> > just modules, some of which may have elements of their name 
> in common.
> 
> Do you really not think that it is useful to think of systems 
> as being composed out of other subsystems? For example, 
> vm-building consists of building the interpreter and stuff, 
> but also of building plugins. And Morphic consists of 
> subsystems and so on.

Actually, I do.  It's just that I don't think the hierarchy of modules
should infer any of those relationships.  In a lot of cases,
"submodules" will have dependencies on their parent.  But these
dependencies should not be inferred by the mere fact that they live in a
similar location in the module hierarchy.  There are also a lot of
counter examples where no dependency relationship will exist (i.e,
submodules of "People xyz").  The upshot of not inferring any
relationships out of the hierarchy is that the module code will be a lot
simpler.  

I believe that the Java package naming mechanism is like this (and I
think they are correct in this regard).  Also, the DNS system works like
this  (i.e. there is no relationship between squeak.org and org, other
than you might need to ask org how to get to squeak.org...which is a
design that we can leverage in our own module system at a later date). 

> I think this is especially important with systems as complex 
> as Squeak.

Again, I agree.  We will need tools that allow you to explore and
traverse modules dependency paths.  The downside of looking at the
module hierarchy and trying to infer dependencies is that it doesn't
give you the whole story.  This is really bad if you're a newbie and
think that it's giving you the whole story about dependencies.

> The parent-submodule relation is just a way of capturing that 
> natural hierarchical structure. Without this, the parts of 
> Morphic would be no more related to Morphic than to the 
> Collection classes for instance.

Sure...again, in a lot of cases, submodules will depend (or co-depend)
on parent modules.  I just don't believe there is any reason to attempt
to force this in the module code.  I can look at the submodules of
"People xyz" and intuitively know that there is probably no dependency
relationship with its submodules.  However, looking at the Morphic
module, I would guess that there are likely to be some dependencies.
Now, there is no reason not to have the ability to do things like load
or unload an entire tree of modules.  I'm simply saying that the
hierarchy should not attempt to force things like implied namespace
imports or implied dependencies.  I think we can really simplify things
if we don't do that.  We have all the capabilities to do that if we need
to through module imports and dependencies.

- Stephen