🚀 go-pugleaf

In article <1991Mar25.210620.13970@world.std.com> wmm@world.std.com (William M Miller) writes:
>gyro@kestrel.edu (Scott Layson) writes:
>> 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?
>
>I'd put "balance" into the base class as a simple matter of factoring: every
>Account will have one, so it's most convenient to put it once and for all
>into the base class instead of having to declare it over and over again in
>each derived class.  If I had a situation in which derived classes needed to
>be able to manipulate each other's data, I'd probably make them mutual
>friends; I don't think it would have occurred to me to put the data into the
>protected section of the base class.

Making the two classes mutual friends doesn't address the situation in
question, which is that B and some set of other classes are all
derived from A, and a member function of B has got hold of some object
other than *this which is some kind of A, but it doesn't know anything
else about it, and it wants to have access to that A just as it would
to the A within *this.  What you would have to do is make each derived
class of A be a friend of A.

I think this observation pinpoints what is so surprising about the
restriction.  People want to think of friendship and derivation in the
same way, and here's a case where they turn out to be different.

I was at one point trying to generate a proposal for unifying the two,
in fact, more or less along these lines: let friendship grant only
protected member access, and let it be inherited and transitive.  I
didn't think about that long enough to decide whether I really
considered it a good idea, but there's no question it would make the
language simpler to think about.

Keep in mind that the current distinctions between inheritance and
friendship vis-a-vis access rights are in part historical: when
friendship was invented, there were no protected members.  It's true
that the unification I propose would eliminate some access
restrictions (including the one under discussion), but it would also
introduce a whole new set, making it possible for a class to restrict
the interface its friends, as well as its derived classes, see.

>>              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'm afraid I don't see the relationship here.

Only that when I first bumped my head against the rule in question, I
scratched my head and thought "what's going on here -- the unit of
protection is the class".  I'm agreeing with you that this is a
confused association -- that's what I was trying to say -- but in my
experience it's a likely confusion.  But no matter.

>> Since there's another way to achieve the protection you want...
>
>This sounds like the argument over passive restraints versus seatbelts.
>It's nice to have that airbag in the steering column in case I forget to
>buckle up or in case I decide that it's only a short, safe trip -- but it's
>not free.

Now *I'm* confused -- it sounds like you're making my argument for me.
That is, I identify the airbag with the access restriction in question
-- it's there whether I want it or not, and you're quite right, it
does cost me something.

-- Scott Layson Burson
Gyro@Reasoning.COM