🚀 go-pugleaf

gyro@kestrel.edu (Scott Layson) writes:
>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.
>
>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.

Again I think you are missing the point. The point is not whether you can
design your way around a hole in the protection mechanisms of the language,
but whether relaxation of this rule creates the possibility for programmer
error that need not exist. Using the above rational I could say that GOTOs
are a good idea because anyone using good programming practices won't require
them.

>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"

Which would you rather have a rule that is counterintuitive or one that
is not logicaly consistent with the rest of the type checking system. I
think it is only counterintuitive to those that have not given it much
thought. One way of thinking about it that makes it more intuitive is to
think of those protected members who are accessed through the derived type
as conceptually belonging to that derived type.

The need to treat protected members of the base class this way stems from
the fact that protected members already represent a breach of the protection
mechanism. This breach is made for convience sake, but when combined with
implicit conversion of pointers to objects of a derived class to pointers
to objects of a public base class, you suddenly have the ability for
unrelated derived objects to get at each others data. The result is that
all the protections afforded by the class heirarchy go out the window for
protected data. The simple solution was the obvious one, since protected
data in essence is an extension of the private data of the derived type,
why not simply make the same rules apply to private data and protected
data inherited from a base class.

> 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.

Huh? The rule does *nothing* in any way to shift the unit of protection from
that of the class to the object. Unless I am grossly mistaken *any* object
of the derived class can access protected base class data in any other object
of the same class. If anything this rule modifies the rule about converting
pointers to objects to pointers to one of their public base classes so that
the conversion can not be done in order to access protected data. To me this
seems completely logical and completely consistent.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com