protection for superclass

[Sean Kelly]

Jari-Matti Mäkelä wrote:
> Sean Kelly wrote:
>> Frank Benoit wrote:
>>> If I do this
>>>
>>> class T : private D {
>>> }
>>>
>>> the functionality from Object is no more visible to a user of T.
>>> e.g. container can complain, they cannot access opEqual. Is this the
>>> wanted behaviour?
>> I'd say it is, as in some cases this might actually be desirable.  The
>> class could still be compared as an Object:
>>
>> Object o = new T;
>> Object p = o;
>>
>> assert( o == p );
>>
> 
> Well, this might be true in C++, where you can limit the visibility of
> superclass members in derived classes. AFAIK, in Java public inheritance
> is the only way to do it:
> 
>  class derived extends base { } [Java] is actually
>  class derived : public base { } [C++]
> 
> Now what if [D code here]
> 
>  interface I { void foo() {} }
>  class Base : I { }
>  class Derived : private Base { }
> 
>  Derived abc = new Derived();
>  Base cba = abc;
>  I bar = cba;
> 
> Then abc.foo() would be illegal, but both cba.foo() and bar.foo() would
> be correct. Sounds _somewhat_ confusing to me.

Each class is meeting its own contracts--protected/private inheritance 
merely allow for a bit more (and perhaps too much) leeway in polymorphic 
behavior.  It's a nice option to have, but one that's rarely used, 
particularly in a language that doesn't support multiple inheritance.


Sean