Hi Steven

I agree. I was confused and was believing that submodules imply scope.
This is the prereq relationship that implies scope.
I do not like the hierarchy (named) approach.

Stef

On Tuesday, May 7, 2002, at 02:57  PM, Stephen Pair wrote:

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