Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!petergo From: petergo@microsoft.UUCP (Peter GOLDE) Newsgroups: comp.std.c++ Subject: Re: "module" facility for top-level namespace control Keywords: namespace, module Message-ID: <71998@microsoft.UUCP> Date: 22 Apr 91 20:50:19 GMT References: <1991Apr19.163253.22253@kestrel.edu> <1991Apr19.183922.1982@kodak.kodak.com> <5143@lupine.NCD.COM> Reply-To: petergo@microsoft.UUCP (Peter GOLDE) Distribution: comp.std.c++ Organization: Microsoft Corp., Redmond WA Lines: 54 In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >It is (or will be in future) reasonably easy to package up all of the things >that we now put into include files and give them all their own little >namespaces by wrapping them in `class { ... }'. (Note that >you will have to declare all data member and function member as "static" >if you want the effect of a "module" however.) > >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. > > [proposed 'use' clause to get around this naming problem] No need to invent new language structures -- use private inheritance. For example, your class wants to use several libraries. Each of these libraries is packaged into a big class, with nested classes for the real functionality, and maybe a couple of static functions, etc. I.e., instead of CARSTUFF.H: const int NumTires = 4; class Tire {...}; class Axle {...}; class Manifold {...}; You do CARSTUFF.H: struct CARSTUFF { static const int NumTires; class Tire {...}; class Axle {...}; class Manifold {...}; }; Now consider what would have been a problem before: you want to use both the CARSTUFF library, and the TOPOLOGY library, both of which define (different) Manifold classes. But you don't want to qualify the non-conflicting names, like Axle and MetricSpace. No problem: class MyClass: private CARSTUFF, private TOPOLOGY { CARSTUFF::Manifold my_auto_manifold; TOPOLOGY::Manifold my_topological_manifold; HausdorffSpace space; Axle axles[2]; }; Peter Golde petergo%microsoft@uunet.uu.net