>> You can also send uppercase messages to a module to access its
>> submodules. So if moduleA has a submodule named ModuleB:
>> 
>> moduleA ModuleB
>> This will return the submodule. Ie. the message is the exact name of the
>> submodule.
>> </citation>

This was actually Dan Ingalls' suggestion way back in the earliest phase of
the last modules discussion round. I had a different suggestion that may
well be buried and forgotten!

>> 
>> I don't like this idea. It sacrifies regularity of the syntax for a tiny
>> benefit.

It's always easy to dis an idea, and it's especially easy to dis new ideas
and say that you like the old way better. It is however more difficult to
produce better solutions. In particular, the position "I want modules but I
also want everything to stay exactly the same as it was before" seems to
come up surprisingly often.

So, what do you suggest instead? I hope you realize that inter-module name
references are a new construct, and a new convention is needed for making
them. If you try to get around this type of reference, you get into a
bootstrapping problem.

In general I think Doug's comments were thoughtful and to the point, but I
have a few additional comments.

- The doesNotUnderstand: hack is really just a temporary solution. Right now
unqualified accesses are still allowed to enable old code to continue
working.

> This would require that your module imports ("uses") the Morphic-Core-Basic
> module.  I tend to think that this is probably the best practice of the
> three... assuming there's some sort of reasonable UI for easily making modules
> import other modules, etc, in as automated a fashion as possible.
> 
> In fact, I'd go as far to say that I would always import modules (like example
> 3) when writing code, and never use explicit paths in my code, the *only*
> exception being when there's an actual class name clash in my imported
> modules, and then of course I would need an explicit path in the code.  (I'd
> be curious to hear other opinions on this, though.)

- Importing all names has many problems of its own, and indeed you still
would need the ability to disambiguate somehow. But it is generally
considered better practice to be explicit about where a name comes from,
than to import a name. E.g. when creating Oberon, Wirth removed the ability
to import names like you could in Modula-2.

But like I said above, what do you suggest instead?

Henrik