If I wish to re-shape the interface to a lower-level library, is there a clean way in D to do this? For example, can one inherit a superclass as private or protected?

Other alternatives include wrapping the superclass via composition, but that's not always practical or desirable.

Any ideas?

- Kris

BTW, 0.81 happily accepts the following declaration:

class Foo : private Bar
{
}

but it doesn't have any effect on the visibility of Bar. Would be nice if it did! Comments?

- Kris


"Kris" <someidiot@earthlink.net> wrote in message news:c3thl7$23co$1@digitaldaemon.com...
> If I wish to re-shape the interface to a lower-level library, is there a clean way in D to do this? For example, can one inherit a superclass as private or protected?
>
> Other alternatives include wrapping the superclass via composition, but that's not always practical or desirable.
>
> Any ideas?
>
> - Kris
>
>

Kris wrote:
> BTW, 0.81 happily accepts the following declaration:
> 
> class Foo : private Bar
> {
> }

You could still cast the Foo object to Bar and access it. If you don't want Bar accessible, why not make it a private member rather than using inheritence? Or if you must use inheritence, you could override the members you want private and call assert(0), then call super.member from within the class to call Bar's member instead of Foo's.


> 
> but it doesn't have any effect on the visibility of Bar. Would be nice if it
> did! Comments?
> 
> - Kris
> 

-- 
Christopher E. Miller

Kris wrote:

>BTW, 0.81 happily accepts the following declaration:
>
>class Foo : private Bar
>{
>}
>
>but it doesn't have any effect on the visibility of Bar. Would be nice if it
>did! Comments?
>
>- Kris
>  
>
I complained about a similar issue before (being about to change the visibility of individual methods like you can in C++), so I agree.  This should be possible.

-- 
-Anderson: http://badmama.com.au/~anderson/

Vathix wrote:

> Kris wrote:
>
>> BTW, 0.81 happily accepts the following declaration:
>>
>> class Foo : private Bar
>> {
>> }
>
>
> You could still cast the Foo object to Bar and access it. If you don't want Bar accessible, why not make it a private member rather than using inheritence? 

This is a good idea, except you lose polymorphism to some extent.  Often you want to be able to make lower levels visible by polymorphism but hide things in the higher levels.  For example events (mouse move ect..) should be visible in the low level but not in the high level because you only want the even handler calling these.  Allowing the user of the higher level class access just makes things more complicated.

> Or if you must use inheritence, you could override the members you want private and call assert(0), then call super.member from within the class to call Bar's member instead of Foo's.

This is not a good idea. Apart from the confusion to the user of the class, there is a lot of work involved to do this. And what if more methods are added to the base class?  You have to then maintain two classes.

-- 
-Anderson: http://badmama.com.au/~anderson/

On Thu, 25 Mar 2004 17:04:32 -0500, Vathix wrote:
> You could still cast the Foo object to Bar and access it. If you don't want Bar accessible, why not make it a private member rather than using inheritence? Or if you must use inheritence, you could override the members you want private and call assert(0), then call super.member from within the class to call Bar's member instead of Foo's.

Private inheritance is useful because it makes the "is implemented in
terms of" relationship explicit. Public inheritance doesn't mean the same
thing ("is-a"), and niether does composition ("has-a").

I think "say what you mean" is a good way to program. You shouldn't always need to guess ;)

Mike Swieton
__
Human salvation lies in the hands of the creatively maladjusted.
	- Martin Luther King, Jr.