Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: MI and namespaces
Keywords: MI namespaces
Message-ID: <11541@ulysses.homer.nj.att.com>
Date: 18 May 89 14:36:29 GMT
References: <192@mole-end.UUCP>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector.UUCP (Jerry Schwarz)
Organization: AT&T Bell Laboratories
Lines: 40

In article <192@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes:

>
>Making the base class private and making public only the members you mean to
>use may or may not solve the problem, depending on whether invisible private
>members can create an ambiguity with visible ones.  (I've heard it both ways,
>most recently that they can.  Will some very knowledgable person please
>straighten me out?)
>

The basic principle in C++ visibility control is that the use of
"public", "protected", and "private" do not change the meaning of a
program, they only affect its legality.

This principle has some drawbacks, in particular it means that the
presense of private members somewhere in an inheritance hierarchy may
create a conflict with public ones.

It has the advantage that it is simple to state and understand.

>I fear that inheriting from lots and lots of base classes to get a variety of
>capabilities is almost sure to lead, sooner or later, to enough ``print''s and
>``dump''s and ``debug''s and ``verify''s that we are either going to begin
>prefixing these names with the class qualifer out of habit or we are going to
>prepend the class's name to the member name we would like to use.  

I suggest that when you derive a class D from multiple base classes
that both have a "print", or "dump", you have a real ambiguity and
the programmer must resolve it by supplying a "D::print" a "D::dump",
etc.

> This will
>indicate (to me at least) that the name space controls we have are inadequate.

I agree that MI makes it more delicate to add members to base
classes.  There has always been the potential for problems when you
do this, but they are more likely to arise in the presense of MI.

Jerry Schwarz
AT&T Bell Labs, Murray Hill