Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!jarthur!petunia!kestrel.edu!gyro
From: gyro@kestrel.edu (Scott Layson)
Newsgroups: comp.std.c++
Subject: Re: protected != public-to-derived
Message-ID: <1991Mar25.183627.6041@kestrel.edu>
Date: 25 Mar 91 18:36:27 GMT
References: <1991Mar19.165333.23908@asc.slb.com> <1991Mar24.010442.27298@kestrel.edu> <1991Mar24.205156.10206@world.std.com>
Organization: Kestrel Institute, Palo Alto, CA
Lines: 47

In article <1991Mar24.205156.10206@world.std.com> wmm@world.std.com (William M Miller) writes:
>gyro@kestrel.edu (Scott Layson) writes:
>> Since the issue has come up, I am very much interested to hear the
>> committee's current feeling about this rule.
>
>I can't speak for the rest of the committee, but I personally think the
>rationale is pretty reasonable.  It might very well be that Derived1 and
>Derived2 classes have different conventions for managing the protected
>members of their common base class.  If a Derived1 member function were able
>to access the base class protected members via a pointer or reference to the
>base class, because of the conversion rules, it might actually be
>manipulating a Derived2 object in an invalid fashion.  By restricting access
>to use only a Derived1 pointer or reference, you at least have the type
>system working in your favor to avoid this kind of bug.

Let's look at the example given at the top of p. 255 of E&S:

   For example, suppose I am running a bank, and I have many different
   kinds of accounts.  I would like to have a base class, `Account',
   that has information common to all kinds of accounts, including the
   account balance, so a friend of `Account' can walk the list of all
   Accounts and tell me the financial position of my bank at any time.
   Each kind of `Account', however, has its own rules for updating the
   balance ([examples omitted]), so the derived classes which are all
   the different kinds of accounts contain the code for updating the
   balance.  The member functions of checking_accounts, however,
   should not be able to access the balance in an `AutoLoan_account'.
   The restriction prevents that.

An easy way to implement this, in the absence of the restriction, is
that `Account' should not own the `balance' member variable, but that
`Account' should provide a private virtual function for retrieving the
balance.

Put another way, why do you want to make `balance' a member variable
of `Account' if you *don't* want the derived classes of `Account' to
be able to access each other's balance?

Since there's another way to achieve the protection you want, and
since the restriction is demonstrably counterintuitive to a lot of
people -- a) it contradicts the simple rule "protected = public-to-
derived" and b) it goes against the grain of "the unit of protection
is the class, not the object" (I'm not saying it literally contradicts
that philosophy, only that it seems to) -- I oppose it.

-- Scott Layson Burson
Gyro@Reasoning.COM