🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #1046

Re: "module" facility for top-level namespace control

#1046
From: Ron Guilmette
Date: Sat, 27 Apr 1991 00:35
53 lines
2679 bytes
Withe regard to the `module {}' discussion...

In article <1991Apr21.172735.1123@lth.se> dag@control.lth.se (Dag Bruck) writes:
>In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>>... { one problem with modules is } ...
>>... 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?
>
...
>	class Foo : private Modulename { ... };
>
>I think it would solve the problem of "getting into" the module for code
>packaged in classes.

I agree, but that's *not* a good enough general solution.  I want to be
able to use the stuff which is encased in a "module" even when I'm not
in some class (or class member function).

>Another property I like in Modula-2 is to be able to selectively
>import names from a module, i.e.,
>
>	IMPORT fission FROM Atomic;

Language designers have gone back and forth on this issue over time.

In some languages, you can EXPORT everything from a module.
In some languages you can EXPORT a just an explicit list of names from a module.
In some langauges you can IMPORT everything from a module.
In some languages you can IMPORT a just an explicit list of names from a module.


Of all these possibilities, I like the way that Ada and C++ both seem to
handle things.  Specifically:

	In Ada (and C++) you don't have to say anything special to
	export names from a package (or a class in the case of C++).
	Neither do you have to say anything explicit in order to get at
	(i.e. "import") the names from that package (class) into any
	scope where the package (class) itself is visible.

	In both languages you do however have some control over what does
	and does not get exported from a package (class).  You exercise
	this control by breaking up the package (class) into public and
	private parts.  That is a sufficient degree of control to satisfy
	me (if not others).

-- 

// Ron ("Loose Cannon") Guilmette
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.
Technical Details
Message-ID: <5280@lupine.NCD.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
References: <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> <1991Apr21.172735.1123@lth.se>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c++
Subject: Re: "module" facility for top-level namespace control
Keywords: namespace, module
Message-ID: <5280@lupine.NCD.COM>
Date: 27 Apr 91 00:35:26 GMT
References: <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> <1991Apr21.172735.1123@lth.se>
Distribution: comp.std.c++
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 53