🚀 go-pugleaf

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 <identifier> { ... }'.  (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