Class and Interface Fun

John Reimer terminal.node at gmail.com
Sun Jan 25 08:22:04 PST 2009


Hello Daniel,

>>>>> [snip]
>>>>> 
>>>>> B inherits all the functions from A implicitly. You stil may
>>>>> override any of the I interface functions if need be:
>>>>> 
>>>>> class B : A, I
>>>>> {
>>>>> override void foo() { ... }
>>>>> // int bar() is inherited from A
>>>>> }
>>>>> Having B explicitly override all the base class virtual functions
>>>>> and forward them to A implementation just to make compiler happy
>>>>> is unintuitive and plain dumb to me.
>>>>> 
>>>>> C# allows that and I see absolutely no reason why D doesn't.
>>>>> 
>>>> I think you are missing somethinghere. Change the B definition
>>>> from:
>>>> 
>>>> class B : A, I
>>>> 
>>>> to just:
>>>> 
>>>> class B : A
>>>> 
>>>> then interfaces become impicit.
>>>> 
>>> No, I don't:
>>> 
>>> class B : private A, public I
>>> {
>>> }
>> Other example:
>> 
>> interface IOStream : InputStream, OutputStream
>> {
>> }
>> class A : InputStream
>> {
>> // implement InputStream
>> }
>> class B : A, IOStream
>> {
>> // implement OutputStream interface *only*
>> }
>> You can't define B like this: class B : A, OutputStream { ... }
>> because this way it won't be castable to IOStream.
>> 
> I believe the rationale behind this is so that you can't implement an
> interface "by accident."  For example, you might be implementing an
> interface, miss one method, and not know because the base class
> implements it.
> 
> Alternately, you might be relying on such inheritance.  Then, the base
> class changes, and you're left with compile errors and wondering why
> it doesn't work.
> 
> Forcing you to specify each method removes this ambiguity from the
> code.
> 
> That said, I could have SWORN that aliasing a method from the
> superclass worked.  If this isn't a bug, it should be.
> 
> Personally, yes it is a bit tedious, but this is why we have templates
> and mixins...
> 
> -- Daniel
> 


Incidentally, concerning having to explicitly alias superclass methods to 
make them visible in the subclass, I used to dislike it greatly in D.  But 
now, I've come to appreciate it more since it /clearly/ specifies which mehtods 
of the superclass you want to use in the subclass.  For example, in Java, 
this isn't necessary... and in a very large project like the swt (java) port 
to D, there have been times that it's been a major pain trying to track a 
call made in a subclass method that references an implicitly inherited superclass 
method.

To me, the D alias system doesn't always look that pretty in this context... 
but it is certainly very useful.

-JJR




More information about the Digitalmars-d-learn mailing list