www.digitalmars.com         C & C++   DMDScript  

D - Interface behavior

reply Joe Battelle <Joe_member pathlink.com> writes:
The fact that interfaces are snapshots and not inherited from class to subclass
can really mess you up sometimes.  Just tacking on the interface at each level
in the hierarchy doesn't work either--you get a unique interface each time.
Casting to a superclass before casting to the interface that the derived type
supports can alter which version of the interface is called.  The spec doesn't
say much about this.

Are we stuck with this feature of interfaces or will they be inheritable at some
point?

Example code:
-------------
import c.stdio;

interface D {
abstract int foo();
}

class A : D {
int foo() { return 1; }
}

class B : A, D { //carry the D's, 'cause they're not inherited
//this should tell you something's up :)
//A's foo is taken to satisfy D.
//a cast(D) on a B will always use this foo
//even if the B is actually a further derived type with overloaded foo()
}

class C : B, D {
int foo() { return 2; }
}

int main (char[][] args)
{
C c = new C;
A a = (A) c;
int j = a.foo(); // 2
B b = (B) c;
int k = b.foo(); // 2
D d1 = (D) c;
int l = d1.foo(); // 2
D d2 = (D) b;
int m = d2.foo(); // 1 Gotcha!!!  b.foo() not equal to (D)b.foo()

//prints 2 2 2 1
printf("%d %d %d %d", j, k, l, m);

return 0;
}
Aug 20 2002
parent reply "Walter" <walter digitalmars.com> writes:
There is a bug here, but I also want to ask what should happen with both A
and C implement D?

"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:ajv33k$2ntc$1 digitaldaemon.com...
 The fact that interfaces are snapshots and not inherited from class to

 can really mess you up sometimes.  Just tacking on the interface at each

 in the hierarchy doesn't work either--you get a unique interface each

 Casting to a superclass before casting to the interface that the derived

 supports can alter which version of the interface is called.  The spec

 say much about this.

 Are we stuck with this feature of interfaces or will they be inheritable

 point?

 Example code:
 -------------
 import c.stdio;

 interface D {
 abstract int foo();
 }

 class A : D {
 int foo() { return 1; }
 }

 class B : A, D { //carry the D's, 'cause they're not inherited
 //this should tell you something's up :)
 //A's foo is taken to satisfy D.
 //a cast(D) on a B will always use this foo
 //even if the B is actually a further derived type with overloaded foo()
 }

 class C : B, D {
 int foo() { return 2; }
 }

 int main (char[][] args)
 {
 C c = new C;
 A a = (A) c;
 int j = a.foo(); // 2
 B b = (B) c;
 int k = b.foo(); // 2
 D d1 = (D) c;
 int l = d1.foo(); // 2
 D d2 = (D) b;
 int m = d2.foo(); // 1 Gotcha!!!  b.foo() not equal to (D)b.foo()

 //prints 2 2 2 1
 printf("%d %d %d %d", j, k, l, m);

 return 0;
 }

Aug 20 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
In article <ajvc6e$31e0$1 digitaldaemon.com>, Walter says...
There is a bug here, but I also want to ask what should happen with both A
and C implement D?

(can't?) specify it at more than one level in the hierarchy--but maybe there's an implementation obstacle to this? Otherwise, you just get deeper and deeper... Right now there is no compile-time enforcement of interface specifications, so I'm not absolutely sure what you're intending for them :) Interfaces seem to be unique for each subclass, and seem to be built from the point of view in the inheritance graph of the derived class. This makes it look like interfaces themselves are inherited and can be overriden, especially in the code below, where you can sandwich a class not having the interface between two that do--and yet the sandwiched class has an effect on the interface of the final derived class (that specifies, but doesn't implement the interface.) On the other hand, right now you can create holes in the interface graph as the crash on use of the sandwiched class directly shows. ---------------- import c.stdio; interface D { abstract int foo(); } class A : D { int foo() { printf("A"); return 0; } } class B : A { int foo() { printf("B"); return 1; } } class C : B, D { //this hides B's foo--note altered return type void foo() { printf("C"); } } int main (char[][] args) { C c = new C; D d = (D)c; c.foo(); //C--makes sense; we're hiding D's foo d.foo(); //B--Whoah! The D interface takes a snapshot at C of the //inheritance hierarchy bringing in to the interface whatever //matches exactly. //OK, so B participates in C's D, but does B inherit D from A? B b = new B; if ((D) b) { //This succeeds so B must printf("X"); D d = (D) b; version(crash) { d.foo(); //CRASH; guess not //Should this be A? } } //while I'm at it: D d1 = new D; //what does that do? compiles fine. return 0; }
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
Ok, so are you saying that interfaces should be "virtually" inherited, i.e.
no matter how many times they appear in the inheritance heirarchy there is
only one instance of them?

"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:ajvq0n$gpf$1 digitaldaemon.com...
 In article <ajvc6e$31e0$1 digitaldaemon.com>, Walter says...
There is a bug here, but I also want to ask what should happen with both


and C implement D?

(can't?) specify it at more than one level in the hierarchy--but maybe

 an implementation obstacle to this?

 Otherwise, you just get deeper and deeper... Right now there is no

 enforcement of interface specifications, so I'm not absolutely sure what

 intending for them :)  Interfaces seem to be unique for each subclass, and

 to be built from the point of view in the inheritance graph of the derived
 class.  This makes it look like interfaces themselves are inherited and

 overriden, especially in the code below, where you can sandwich a class

 having the interface between two that do--and yet the sandwiched class has

 effect on the interface of the final derived class (that specifies, but

 implement the interface.)  On the other hand, right now you can create

 the interface graph as the crash on use of the sandwiched class directly

 ----------------
 import c.stdio;

 interface D {
 abstract int foo();
 }

 class A : D {
 int foo() { printf("A"); return 0; }
 }

 class B : A {
 int foo() { printf("B"); return 1; }
 }

 class C : B, D {
 //this hides B's foo--note altered return type
 void foo() { printf("C"); }
 }

 int main (char[][] args)
 {
 C c = new C;
 D d = (D)c;
 c.foo();    //C--makes sense; we're hiding D's foo
 d.foo();    //B--Whoah! The D interface takes a snapshot at C of the
 //inheritance hierarchy bringing in to the interface whatever
 //matches exactly.

 //OK, so B participates in C's D, but does B inherit D from A?
 B b = new B;
 if ((D) b) { //This succeeds so B must
 printf("X");
 D d = (D) b;
 version(crash) {
 d.foo();  //CRASH; guess not
 //Should this be A?
 }
 }

 //while I'm at it:
 D d1 = new D; //what does that do? compiles fine.

 return 0;
 }

Aug 21 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
Ok, so are you saying that interfaces should be "virtually" inherited, i.e.
no matter how many times they appear in the inheritance heirarchy there is
only one instance of them?

No, I think that is too restrictive. These are the rules I want to see. They are close to what you are doing now. (1) & (3) add compile-time restrictions to your current implementation to close up the holes I demonstrated earlier. (2) fixes what I think is a bug/limitation in your current implementation. 1) Strict specification -- if a D class implements an interface, then the interface must be fully satisfied through methods in the inheritance graph up to and including that class, otherwise you get a compile-time error. interface D { void foo(); } class X : D { char[] foo(); } //ERROR, X doesn't implement D class A { void foo(); } class B : D {} //OK, B satisfies D through A's methods 2) Inheritance of Interfaces -- if a D class implements an interface, then all subclasses of the class will also implement the interface. interface D { void foo(); } class A { void foo(); } class B : A {} This means (D) B is legal. 3) Overriding Interfaces -- if a subclass of a class that implements an interface, overrides a member of that interface then it is a compile-time error, unless the class specifies that it is redefining the interface, whereby a new interface is created from that point in the hierarchy. interface D { void foo(); } class A : D { void foo() {} } class B : A { void foo() {} } //ERROR, redefining D without specifying it class C : B, D { void foo() {} } //OK, we get a new interface here class C : B, D { char[] foo() {} } //ERROR, we didn't override anything in D This will keep your current behavior, but prohibit the bad apples I showed in my other posts.
Aug 21 2002
next sibling parent Joe Battelle <Joe_member pathlink.com> writes:
Sorry--typo, the example code for rule 2 should have been:

interface D { void foo(); }
class A : D { void foo(); } //A implements D
class B : A {} //so does B through inheritance

B b;
(D) b is legal.
Aug 21 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:ak0o22$2opb$1 digitaldaemon.com...
 1) Strict specification -- if a D class implements an interface, then the
 interface must be fully satisfied through methods in the inheritance graph

 and including that class, otherwise you get a compile-time error.

 interface D { void foo(); }
 class X : D { char[] foo(); } //ERROR, X doesn't implement D

Should already be doing that.
 class A { void foo(); }
 class B : D {} //OK, B satisfies D through A's methods

That's the virtual inheritance thing.
 2) Inheritance of Interfaces -- if a D class implements an interface, then

 subclasses of the class will also implement the interface.

 interface D { void foo(); }
 class A { void foo(); }

I think you meant class A:D{void foo(); }
 class B : A {}

 This means (D) B is legal.

Yes.
 3) Overriding Interfaces -- if a subclass of a class that implements an
 interface, overrides a member of that interface then it is a compile-time

 unless the class specifies that it is redefining the interface, whereby a

 interface is created from that point in the hierarchy.
 interface D { void foo(); }
 class A : D { void foo() {} }
 class B : A { void foo() {} } //ERROR, redefining D without specifying it

I guess I don't agree.
 class C : B, D { void foo() {} } //OK, we get a new interface here
 class C : B, D { char[] foo() {} } //ERROR, we didn't override anything in

I tentatively agree.
 This will keep your current behavior, but prohibit the bad apples I showed

 other posts.

I think the bad apple is just a bug in the implementation.
Aug 21 2002
next sibling parent Joe Battelle <Joe_member pathlink.com> writes:
 class X : D { char[] foo(); } //ERROR, X doesn't implement D

Should already be doing that.

 This means (D) B is legal.

Yes.

 interface D { void foo(); }
 class A : D { void foo(); }
 class B : A { void foo() {} } //ERROR, redefining D without specifying it


necessary. On the otherhand I like it because it shows you where in the graph, D can actually change behavior. Thanks for your responses.
Aug 21 2002
prev sibling parent reply Joe Battelle <Joe_member pathlink.com> writes:
 This means (D) B is legal.

Yes.

More bugs for the unittests when interfaces are fixed: interface D { int foo(); } class A : D { int foo() { return 1; } } class B : A { int foo() { return 2; } D me() { return this; } } unittest() { A a = new A; B b = new B; assert(b.me().foo() != a.foo()); } Currently, this gives compilation error: "cannot implicitly convert B to D." Also, as would be expected if you define me() up in A, you get no compile time error, but the current implementation uses A's foo() instead of B's foo() on a call such as b.me().foo().
Aug 22 2002
parent "Walter" <walter digitalmars.com> writes:
Yes, having a set of executable tests to illustrate and validate correct
behavior is very nice. Thanks!


"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:ak44i2$32d$1 digitaldaemon.com...
 More bugs for the unittests when interfaces are fixed:

 interface D { int foo(); }
 class A : D { int foo() { return 1; } }
 class B : A { int foo() { return 2; }
 D me() { return this; } }
 unittest()
 {
 A a = new A;
 B b = new B;
 assert(b.me().foo() != a.foo());
 }

 Currently, this gives compilation error: "cannot implicitly convert B to

 Also, as would be expected if you define me() up in A, you get no compile

 error, but the current implementation uses A's foo() instead of B's foo()

 call such as b.me().foo().

Aug 23 2002