Class and Interface Fun

John Reimer terminal.node at gmail.com
Sat Jan 24 21:49:25 PST 2009


Hello tim,

> On Sun, 25 Jan 2009 17:56:03 +1300, John Reimer
> <terminal.node at gmail.com>  wrote:
> 
>> Hello tim,
>> 
>>> On Sun, 25 Jan 2009 16:43:55 +1300, John Reimer
>>> <terminal.node at gmail.com>  wrote:
>>>> With this code:
>>>> --------------------------------
>>>> module test5;
>>>> interface I
>>>> {
>>>> void foo();
>>>> }
>>>> class A : I {
>>>> void foo() { }
>>>> }
>>>> class B : A, I
>>>> {
>>>> alias A.foo foo;
>>>> }
>>>> void main()
>>>> {
>>>> }
>>>> --------------------------------
>>>> I get this error:
>>>> --------------------------------
>>>> class test5.B interface function I.foo is not implemented
>>>> --------------------------------
>>>> Does this make sense?  I mean, shouldn't the explicit reuse of
>>>> A.foo
>>>> in  B be sufficient indication to the compiler that B is satisfying
>>>> the  contract I?   I'm hoping to make use of such subtleties in
>>>> some
>>>> code,  but first I have to understand the reasoning behind this. :)
>>>> Note that this works if I remove the interface I from B's
>>>> declaration
>>>> --  ie "class B: A" -- since, in the D language, B is not required
>>>> to
>>>> fulfull A's interface contract even though it inherits from it.
>>>> -JJR
>>> It look like the real bug is re-allowing B to implement interface I
>>> but
>>> sometimes bug do get reported differently. Why don't you remove I
>>> from
>>> B's
>>> declaration like you said that works. It actually says here
>>> http://www.digitalmars.com/d/1.0/interface.html "Classes cannot
>>> derive
>>> from an interface multiple times."
>> Yes, please check the link again (further down the page).    D allows
>> you to reimplement the interface as long as class B provides a new
>> implementation:
>> 
>> "A reimplemented interface must implement all the interface
>> functions,  it does not inherit from a super class"...
>> 
>> That probably could be stated a little more clearly, but that's what
>> it  says.  As for why I'm doing it, I assure you that there's a very
>> specific reason why I'm trying this: it is a possible interfacing
>> mechansim for ported software of a much more complicated nature than
>> this simple reduction; I reduced it to this in order to try to
>> understand potential iteractions between class and interface layers.
>> The question here was to figure out the reasoning behind the language
>> design,  not necessarily whether I should be doing it or not. ;-)
>> 
>> -JJR
>> 
> This works btw:
> 
> module test;
> 
> interface I
> {
> void foo();
> }
> class A : I {
> void foo() { }
> }
> class B : A,I
> {
> void foo() { A.foo(); }
> }
> void main()
> {
> }
> 


Yes, I can resort to that if absolutely necessary (but I'd rather not :( 
).  I'm curious why doing a much simpler "alias" doesn't work, since it's 
the D way of making inherited methods accessible to the subclass.

I figured that the "alias" should automatically (re-)implement the interface 
as well.

-JJR




More information about the Digitalmars-d-learn mailing list