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?

"Frank Benoit" <keinfarbton@nospam.xyz> wrote in message news:e3igf5$3lc$1@digitaldaemon.com...
> 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?

Weird, didn't know that that was even legal D.  I guess, after looking at the class spec, that it is, but it's not documented.

What's more, I can't reproduce it.

class A
{

}

class B : private A
{

}

void main()
{
 B b = new B;
 B b2 = new B;

 if(b == b2)
  writefln("knife!");
}

That works fine.  Is there something that your superclass D does perhaps that makes opEquals invisible?

> Weird, didn't know that that was even legal D.  I guess, after looking at the class spec, that it is, but it's not documented.

The class spec allows protection attribute and if you have no base class, Object is an implicit base class. This implies, that a protected inherit encapsulated Object.

> 
> What's more, I can't reproduce it.
> 

If you use the class in the same module, you have always access to every members. Even the private ones. You can only see this, if you place the main in a seperate module.

"Frank Benoit" <keinfarbton@nospam.xyz> wrote in message news:e3j83d$185s$1@digitaldaemon.com...
> If you use the class in the same module, you have always access to every members. Even the private ones. You can only see this, if you place the main in a seperate module.

I got it now.. that's really strange.  And undocumented.

On Sun, 7 May 2006, Jarrett Billingsley wrote:

> "Frank Benoit" <keinfarbton@nospam.xyz> wrote in message news:e3j83d$185s$1@digitaldaemon.com...
> > If you use the class in the same module, you have always access to every members. Even the private ones. You can only see this, if you place the main in a seperate module.
> 
> I got it now.. that's really strange.  And undocumented.

Actually, it is documented:

    http://www.digitalmars.com/d/attribute.html

Read the secton 'Protection Attribute'.

Later,
Brad

"Brad Roberts" <braddr@puremagic.com> wrote in message news:Pine.LNX.4.64.0605062143380.2422@bellevue.puremagic.com...
>
> Actually, it is documented:
>
>    http://www.digitalmars.com/d/attribute.html
>
> Read the secton 'Protection Attribute'.

No, no, I knew about that.  I mean that you can specify a protection attribute for a base class.  Look at the "Classes" spec, you'll notice it's in the syntax, but it's never mentioned in the docs.  And I really didn't expect it to do anything.  Maybe this weird behavior is why Walter never really fleshed it out, or had to abandon the idea (since privately importing Object is a bad thing).  It's probably just a vestige.

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 );


Sean

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.

-- 
Jari-Matti

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