Thread overview | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 02, 2002 New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
From the interface semantics description: " Interfaces can be inherited, but functions are not overridden: interface D { int foo(); } class A : D { int foo() { return 1; } } class B : A { int foo() { return 2; } } .. B b = new B(); b.foo(); // returns 2 D d = (D) b; // ok since B inherits A's D implementation d.foo(); // returns 1; " I am especially confused by the next to last line: D d = (D) b; The reference d has no reason to prefer any particular implementation of "int D::foo()". The comment says that it will use A's implementation due to inheritance, but this line never mentions A. Why would this code do what appears to be an implicit "cast to base class" with no reason? Since B has a perfectly good foo(), I would expect virtual function behavior and that I would get B::foo(). The only thing I can think of is that this is a doc typo, and was supposed to read: D d = (A) b; In which case I'm OK for the example doing what it says it does. That does, however, leave me with the question of what the example -- as it currently exists, with the cast to D -- would print. Would you get the virtual function call to B::foo(), like I would expect, since D has no implementation of its own? Mac |
October 02, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mac Reiter | "Mac Reiter" <Mac_member@pathlink.com> wrote in message news:anf057$1429$1@digitaldaemon.com... > From the interface semantics description: > " Interfaces can be inherited, but functions are not overridden: > > interface D > { > int foo(); > } > > class A : D > { > int foo() { return 1; } > } > > class B : A > { > int foo() { return 2; } > } > > .. > > B b = new B(); > b.foo(); // returns 2 > D d = (D) b; // ok since B inherits A's D implementation > d.foo(); // returns 1; > " > > I am especially confused by the next to last line: > > D d = (D) b; > > The reference d has no reason to prefer any particular implementation of "int > D::foo()". The comment says that it will use A's implementation due to inheritance, but this line never mentions A. Why would this code do what appears to be an implicit "cast to base class" with no reason? Because it will use A's D. > Since B has a > perfectly good foo(), I would expect virtual function behavior and that I would > get B::foo(). The only thing I can think of is that this is a doc typo, and was > supposed to read: > > D d = (A) b; No, it's not a typo. > In which case I'm OK for the example doing what it says it does. That does, > however, leave me with the question of what the example -- as it currently exists, with the cast to D -- would print. Would you get the virtual function > call to B::foo(), like I would expect, since D has no implementation of its own? No, you'd get A.foo(). Joe & I went around on this for a few cycles, and this seemed the best solution. |
October 02, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mac Reiter | If the D docs are correct, I don't like the way interfaces are now implemented. I have some general issues with them but the thing that I think is a big issue is this... B b = new B(); b.foo(); // returns 2 D d = (D) b; d.foo(); // returns 2 A a = (A) b; D d2 = (D) a; // REALLY BIG PROBLEM FOR ME HERE!!! d2.foo(); // returns 1, because it uses A's D, not B's D There are places in my code that I keep arrays of base classes. I act on interfaces of these base classes with the expectation that they use the most derived interface for that class. The only way I can see around this problem now is to do this: interface D { int foo(); } class A : D { int foo() { return 1; } D getDInterface() { return (D)this; } } class B : A, D { int foo() { return 2; } D getDInterface() { return (D)this; } } Now use getDInterface() on the base class to get the correct interface. |
October 02, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Down | I hear you. You might be right. Let's let things percolate a bit and see. -Walter "Patrick Down" <pat@codemoon.com> wrote in message news:Xns929B69618134Dpatcodemooncom@63.105.9.61... > > > If the D docs are correct, I don't like > the way interfaces are now implemented. > > I have some general issues with them but > the thing that I think is a big issue > is this... > > B b = new B(); > b.foo(); // returns 2 > D d = (D) b; > d.foo(); // returns 2 > A a = (A) b; > D d2 = (D) a; > // REALLY BIG PROBLEM FOR ME HERE!!! > d2.foo(); // returns 1, because it uses A's D, not B's D > > There are places in my code that I keep arrays of base classes. I act on interfaces of these base classes with the expectation that they use the most derived interface for that class. > > The only way I can see around this problem now is to do this: > > > interface D > { > int foo(); > } > > class A : D > { > int foo() { return 1; } > > D getDInterface() { return (D)this; } > } > > class B : A, D > { > int foo() { return 2; } > > D getDInterface() { return (D)this; } > } > > Now use getDInterface() on the base class to get > the correct interface. > > > |
October 02, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Um..I don't think what you implemented is what we came up with <g>. "Interfaces can be inherited, but functions are not overridden:" This leads to trouble. If you keep this stance, I advocated not allowing signatures in derived classes that would "cover" the interface ones. "But interfaces can be reimplemented in derived classes:" Here the real question is does a.foo()==d2.foo()? If not, again people will be upset. I don't have time for a full reply right now, I'll go back through my posts and then resummarize if necessary. |
October 03, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joe Battelle | This is the relevant message, I infer there's a bug in it <g>: 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 "Joe Battelle" <Joe_member@pathlink.com> wrote in message news:anffo9$1kfl$1@digitaldaemon.com... > Um..I don't think what you implemented is what we came up with <g>. > > "Interfaces can be inherited, but functions are not overridden:" > This leads to trouble. If you keep this stance, I advocated not allowing > signatures in derived classes that would "cover" the interface ones. > > "But interfaces can be reimplemented in derived classes:" > Here the real question is does a.foo()==d2.foo()? If not, again people will be > upset. > > I don't have time for a full reply right now, I'll go back through my posts and > then resummarize if necessary. > > |
October 03, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Down | "Patrick Down" <pat@codemoon.com> wrote in message news:Xns929B69618134Dpatcodemooncom@63.105.9.61... > > > If the D docs are correct, I don't like > the way interfaces are now implemented. > > I have some general issues with them but > the thing that I think is a big issue > is this... > > B b = new B(); > b.foo(); // returns 2 > D d = (D) b; > d.foo(); // returns 2 > A a = (A) b; > D d2 = (D) a; > // REALLY BIG PROBLEM FOR ME HERE!!! > d2.foo(); // returns 1, because it uses A's D, not B's D > > There are places in my code that I keep arrays of base classes. I act on interfaces of these base classes with the expectation that they use the most derived interface for that class. > > The only way I can see around this problem now is to do this: > > > interface D > { > int foo(); > } > > class A : D > { > int foo() { return 1; } > > D getDInterface() { return (D)this; } > } > > class B : A, D > { > int foo() { return 2; } > > D getDInterface() { return (D)this; } > } > > Now use getDInterface() on the base class to get > the correct interface. Wow. So you are emulating the Right behaviour. Anybody can please put in an example here where this non-virtual interface is usefull? |
October 03, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Why not have an 'overide' keyword so you can explicitly state when you want the derived class function to overide the base class function? chris "Walter" <walter@digitalmars.com> wrote in message news:anf6fl$1aj0$1@digitaldaemon.com... > I hear you. You might be right. Let's let things percolate a bit and see. -Walter > > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns929B69618134Dpatcodemooncom@63.105.9.61... > > > > > > If the D docs are correct, I don't like > > the way interfaces are now implemented. > > > > I have some general issues with them but > > the thing that I think is a big issue > > is this... > > > > B b = new B(); > > b.foo(); // returns 2 > > D d = (D) b; > > d.foo(); // returns 2 > > A a = (A) b; > > D d2 = (D) a; > > // REALLY BIG PROBLEM FOR ME HERE!!! > > d2.foo(); // returns 1, because it uses A's D, not B's D > > > > There are places in my code that I keep arrays of base classes. I act on interfaces of these base classes with the expectation that they use the most derived interface for that class. > > > > The only way I can see around this problem now is to do this: > > > > > > interface D > > { > > int foo(); > > } > > > > class A : D > > { > > int foo() { return 1; } > > > > D getDInterface() { return (D)this; } > > } > > > > class B : A, D > > { > > int foo() { return 2; } > > > > D getDInterface() { return (D)this; } > > } > > > > Now use getDInterface() on the base class to get > > the correct interface. > > > > > > > > |
October 03, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | >This is the relevant message, I infer there's a bug in it <g>: I don't see it. Ignore the issue about whether (D)(A)b.foo() should be the same as (D)b.foo(), when both A and B implement D for the moment. I'll come back to this in another post. What I was addressing with the post you quoted was if (A)b.foo()==(D)b.foo() when only A implements D, B doesn't specify D (silently inheriting it), but overrides foo() thereby covering D's foo(). This leads to the bizarre situation where (A)b.foo()!=(D)b.foo() where D is only specified at A. Quoting the relevant line: >class B : A { void foo() {} } //ERROR, redefining D without specifying it This is not illegal in your current implementation. We discussed this, and I think you were against it (I think). But that only makes sense if inherited interfaces can also be overriden (which I though you were implementing), so that B's foo automatically alters B's inherited D interface,which it does not in your implementation. |
October 07, 2002 Re: New (?) Interface semantics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "Walter" <walter@digitalmars.com> wrote in news:anf6fl$1aj0$1 @digitaldaemon.com:
> I hear you. You might be right. Let's let things percolate a bit and see. -Walter
>
So was any decision reached about how interfaces
should work?
|
Copyright © 1999-2021 by the D Language Foundation