Le_Forgeron wrote:

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

But with this logic, the example Warp posted should also be forbidden.

I didn't try it myself but if the behavior is as described in this
thread it would mean protected access is restricted as follows:

Type/Instance This  Other

Parent        Ok    Fail

Same          Ok    Ok

Which I too find a bit odd.

Post a reply to this message

Le 29/11/2010 00:22, Christian Froeschlin a écrit :
> Le_Forgeron wrote:
> 
>> X & Y are both Policemen, but each one keep his/her/its gun protected.
> 
> But with this logic, the example Warp posted should also be forbidden.

Right, so you found a failure in the analogy when pushing it further
than intended.
I won't refine it, can you imagine policemen from the same specialised
activity sharing their gun ?

> 
> I didn't try it myself but if the behavior is as described in this
> thread it would mean protected access is restricted as follows:
> 
> Type/Instance This  Other
> 
> Parent        Ok    Fail
> 
> Same          Ok    Ok
> 
> Which I too find a bit odd.

Not so odd, if you consider that, from the point of view of knowing the
implementation, the failing case is just missing a friend to be ok;
Or turning it otherwise, the scope of calling other(B) when inside B is
ok, whereas the scope of calling other(A) when inside B is not.
(scope is different, hence the failure).

The sub-problem to forbid the warp's case would be if the called method
was a class method (not per instance, just per class)... it would
generate more problems.

Encapsulation principle: if you are the programmer in charge of B, you
do as you want with all the B, as long as it stays in B.

Protected:

    * Can be data and method members
    * Exactly same as private members for all practical purposes except
for the inheritance part
    * These members are inherited by a child of the class in which they
are declared
    * Their behaviour in the child class depends on how the inheritance
has been defined
    * If the inheritance is private these are private in the child
class; if it is public these are public in the child class and if the
inheritance in protected these are protected in the child class thus
allowing further inheritance.

Private:

    * Can be data or method members
    * Are accessible ONLY thru other methods of the same class where
they are declared
    * Cannot be accessed thru a class instance
    * Will not be inherited


-- 
Those who would give up Essential Liberty to purchase
a little Temporary Safety, deserve neither Liberty nor Safety.

Benjamin Franklin

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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'd say you can think of it like when B inherits A, B inherits the
protected section of A, and it thus becomes also B's own protected section.
B can access its own protected section, but not A's protected section.
The distinction comes into play when you have an object of type B vs. an
object of type A. B can access the protected section of the former (because
it is part of B's protected section), but not the protected section of the
latter (because now it's purely A's protected section, not B's).

  (I'm not saying that this is a perfect design, or that it makes perfect
sense. I'm just describing the situation.)

  If you know that the object behind the pointer is really of type B, you
can make a cast to B. If the object has RTTI you can make a dynamic cast
to test if the object is of type B. If it's not of type B, then you just
can't call its protected section.

-- 
                                                          - Warp

Post a reply to this message