Le 28/11/2010 18:28, clipka nous fit lire :
> Am 27.11.2010 21:01, schrieb Le_Forgeron:
>> (1) is ok because B is an A, so can access the protected function.
>> (2) is not allowed because a() of A is protected, so can only be called
>> by the object itself (in a gross simplification).
>>
>> Works as designed.
> 
> Is that so?
> 
> Why should (2) be prohibited when (1) is not? After all, the practical
> use of protected members is to hide implementation details from "alien"
> code; but the code in (2) is not alien - it must rely on that
> implementation detail called "a()" even if it just calls it on itself,
> so why prevent it from calling it on some other object of type A?
> 
> I can see how this /could/ be intended, but I'm not so sure whether it
> /is/ intended. At least it is unexpected for me, and makes life more
> cumbersome than necessary.

You should thinks "object oriented" as "public is what is available to
everyone, private is for myself only. Protected is a mixed path to allow
inheriting classes & friends to also have access to it.".

Whenever an instance X of an object has a reference to an instance Y
does not allow the methods of X to access the protected & private area
of Y, even if X & Y are from the same class.

Illustration with gun (protected method) & policeman (class):

Policeman X can use its gun (gun is protected, so other normal people do
not have access to it!)
Policeman X has to drive policeman Y (so X know about Y).
Nevertheless, Policeman X is not allowed to use the gun of Y directly.

X & Y are both Policemen, but each one keep his/her/its gun protected.

Or do you think the policeman from L.A. should be free to use the gun of
the policeman of N.Y. ? (free as: whenever, wherever, without even the
shadow of a control ?)

Post a reply to this message