Article View: comp.std.c++
Article #1046Re: "module" facility for top-level namespace control
From: Ron Guilmette
Date: Sat, 27 Apr 1991 00:35
Date: Sat, 27 Apr 1991 00:35
53 lines
2679 bytes
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!rfgReferences:
<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