www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - protection for superclass

reply Frank Benoit <keinfarbton nospam.xyz> writes:
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?
May 06 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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?
May 06 2006
parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
 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.
May 06 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
May 06 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
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
May 06 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
May 07 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
May 07 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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
May 07 2006
parent Sean Kelly <sean f4.ca> writes:
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
May 08 2006