Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!odi!valens!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.c++
Subject: Re: Why can't access control be used to disambiguate between ba
Message-ID: <406@odi.ODI.COM>
Date: 4 Aug 89 16:08:19 GMT
References: <2408@ginosko.samsung.com> <13073@polyslo.CalPoly.EDU> <9716@alice.UUCP> <20951@cup.portal.com>
Sender: news@odi.com
Reply-To: dlw@odi.com
Lines: 48
In-reply-to: Tim_CDC_Roberts@cup.portal.com's message of 2 Aug 89 18:57:06 GMT

In article <20951@cup.portal.com> Tim_CDC_Roberts@cup.portal.com writes:

   I have to agree with Mr Wang.  It seems to me that a compiler should be
   able to disambiguate the following modification of your example:

       class A { private int x; };
       class B { public int x; };
       class C: A, B { };

	   c.x = 5;                // Since c.A::x does not exist, as far
				   // as C is concerned, this should NOT
				   // be ambiguous and should be allowed.

Here's my understanding of why things work the way they do.  As we
have seen from previous postings, the C++ philosophy is NOT that
"c.A::x does not exist".  It does exist.  You're just not allowed to
access it.

That is, what C++ calls "access control" is really "access control",
NOT "name hiding".  It's like a locked safe in a bank; you can't get
into it, but you know it's there.  In your example, both varibles are
visible, and so the reference is ambiguous, even though you are only
granted access to one of them.  The ambiguity is between "yes, here,
you can have the value from class B" and "error, you may not reference
the value from class A", and there's no way know which is the proper
thing for the compiler to generate.

Exactly the same issue arises in SINGLE inheritance as well; this is
not an issue specific to multiple inheritance.  Namely, if I write a
class, with a private data member "a", and then you want to subclass
it, and you happen to choose "a" as the name of a data member, you'll
get an error message from the compiler.  The name "a", although
private, is still apparent to the subclass writer; there is no name
hiding here.

ARK recently pointed out one advantage of this arrangement: if the
base class writer later chooses to make "a" public instead of private,
he need not worry about causing conflicts with existing subclasses.

(Personally, I think that a name-hiding approach would have more
conducive to proper modularity, and appeals to me more.  While
agreeing with ARK's point about the advantage, I think I would have
made the tradeoff the other way.  Of course, there may be other
important language design considerations that I am not aware of; the
implications of such a change could be felt in many places, and might
cause other effects.  Anyway, it's all quite academic at this point.)

Dan Weinreb		Object Design, Inc.		dlw@odi.com