Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!lth.se!newsuser
From: dag@control.lth.se (Dag Bruck)
Newsgroups: comp.std.c++
Subject: Re: "module" facility for top-level namespace control
Keywords: namespace, module
Message-ID: <1991Apr21.172735.1123@lth.se>
Date: 21 Apr 91 17:27:35 GMT
References: <1991Apr19.163253.22253@kestrel.edu> <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM>
Sender: newsuser@lth.se (LTH network news server)
Distribution: comp.std.c++
Organization: Department of Automatic Control, Lund, Sweden
Lines: 33

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>The problem is *not* one of establishing new "modules" or new "namespaces"
>(which class declarations can do quite well, thank you).  No.  The problem
>is that if you do this, it becomes quite cumbersome to *reference* the
>things whose declarations you have now nested within class declarations.
>Specifically, it is quite irritating to have to write out the extra
>CLASSNAME:: qualification all over the place.

Wouldn't this be a case were multiple inheritance could be used?

	struct Modulename {
		static ....;
		static ....;
	};

	class Foo : private Modulename {
		....
	};

I think it would solve the problem of "getting into" the module for code
packaged in classes.  Name conflicts only arise when an ambiguous name
is _used_, if I remember correctly, and can be solved with explicit
qualification.

Another property I like in Modula-2 is to be able to selectively
import names from a module, i.e.,

	IMPORT fission FROM Atomic;

I do not see how this very useful feature could be provided with the
class-as-module-and-no-new-keywords-please approach.

		-- Dag Bruck