www.digitalmars.com         C & C++   DMDScript  

D - New (?) Interface semantics

reply Mac Reiter <Mac_member pathlink.com> writes:
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
Oct 02 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"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.
Oct 02 2002
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
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.

 
Oct 02 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
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.
Oct 02 2002
next sibling parent reply Joe Battelle <Joe_member pathlink.com> writes:
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.
Oct 02 2002
parent reply "Walter" <walter digitalmars.com> writes:
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.
Oct 03 2002
parent Joe Battelle <Joe_member pathlink.com> writes:
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.
Oct 03 2002
prev sibling next sibling parent "chris jones" <flak clara.co.uk> writes:
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.
Oct 03 2002
prev sibling parent reply Patrick Down <pat codemoon.com> writes:
"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?
Oct 07 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
So was any decision reached about how interfaces
should work?
Uh, no <g>. Continuing from my last post... If Walter implements the "no cover" rule, then to override an interface necessarily requires the derived class to specify the interface, thereby creating a new instance of the interface at that level in the hierarchy. So the question becomes: does (D)(A)b.foo()==(D)b.foo() when both A and subclass B specify interface D. In the current implementation, the answer is "no." You can only count on "most-derived" interface semantics if you confine yourself to interface references (converted directly from a most derived object reference). If you want to keep a list of A's (containing both A's and B's), and then you convert to D's on demand, you will only get A's version of D. I frankly don't find this so bothersome. What I do care about, is that you get a new interface at each level of the hierarchy in which the interface is specified, and that there must be a way to refer to individual interfaces so that they can be passed to external programs. The main advantage to the "interface per level" approach is that one can use interfaces to communicate with external applications (COM) that access different versions of the component (interface) at the same time, while using inheritence for reuse among versions. This is roughly how interfaces are implemented now. I would hate to lose this in an attempt to switch over to general "most-derived" semantics. So to some up, either Walter makes interfaces work more intuitively (in a D sense) and supports interface inheritence _allowing_ overloading without re-specifying the interface, guaranteeing (A)b.foo()==(D)b.foo(), or Walter makes covering interfaces _illegal_ when not explicitly specifying the interface, and keeps everything else as it is--which better supports external program interfacing. [Wow, that's quite a sentence =] I think it really depends on what people want to use interfaces for. I want to use them to interface to external programs, or as OS calls/callbacks (a la OSKIT) in an embedded system. This requires multiple, predictable interface definitions at the same time--exactly what we have. I know! "Let's have a pragma or compiler switch decide between the two". [kidding...]
Oct 07 2002
next sibling parent Joe Battelle <Joe_member pathlink.com> writes:
So to some up...
There's a convincing way to to begin your summation. [forgive me the self-reply =]
Oct 07 2002
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
Joe Battelle <Joe_member pathlink.com> wrote in
news:antj7j$que$1 digitaldaemon.com: 

So was any decision reached about how interfaces
should work?
Uh, no <g>. Continuing from my last post... In the current implementation, the answer is "no." You can only count on "most-derived" interface semantics if you confine yourself to interface references (converted directly from a most derived object reference). If you want to keep a list of A's (containing both A's and B's), and then you convert to D's on demand, you will only get A's version of D. I frankly don't find this so bothersome.
I think I would find it bothersome. <g> For me, and the majority of purposes that I would use interfaces for, I would certainly desire the most derived object interface. In my view a B is always a B even if I cast it to an A and thus should always present the interfaces implemented on a B class.
 to external programs. The main advantage to the "interface per level"
 approach is that one can use interfaces to communicate with external
 applications (COM) that access different versions of the component
 (interface) at the same time, while using inheritance for reuse among
 versions.  
It seems like this problem could be solved by mapping different internal interfaces to the same external one depending on component version.
 I think it really depends on what people want to use interfaces for. 
I guess when I saw that D had interfaces I expected that they would be like Java's interfaces. The following would be my preferred functionality. interface D { int foo(); } class A : D { int foo() { return 1; } } class B : A // Note don't need to redeclare D { int foo() { return 2; } } A a = new A(); A b = new B(); D da = (D)a; D db = (D)b; da.foo(); // return 1 db.foo(); // return 2 However I expect that Walter would tell me that he doesn't want to implicitly create a D interface vtable for every class derived from A.
Oct 07 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
First, having one hierarchy declare multiple, yet similar interfaces is a mess.
If the public interface hasn't changed, then it's much better if we can continue
to declare a single interface implemented differently at different levels in the
inheritance [got the spelling right finally =] hierarchy.

However I expect that Walter would tell me that he doesn't want to
implicitly create a D interface vtable for every class derived from 
A.
I don't think interfaces should be created implicitly. I think if you want to change the interface, redeclaring it makes perfect sense. This is analogous to the "inserting a call to super" thread. I don't think the compiler should be creating new interfaces without the programmer knowing about it. A seasoned programmer would know in any event with some investigating. But isn't it just as easy to say to the newbie: "you want to change the interface? redeclare it for the derived class. nothing going on behind the scenes. You want to reference a particular version of the interface you do this: (interface)(class) reference. You want the most derived interface? Manipulate interface references directly; don't cast through a base class first." Having said this. I would like to know from Walter how much work it is to generate "implicit" interfaces every time you overload a base classes declared interface. And, how we would refer to these (so as to pass to external apis) if they are implicit.
Oct 07 2002
next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <antvhr$17e7$1 digitaldaemon.com>, Joe Battelle says...
First, having one hierarchy declare multiple, yet similar interfaces is a mess.
If the public interface hasn't changed, then it's much better if we can continue
to declare a single interface implemented differently at different levels in the
inheritance [got the spelling right finally =] hierarchy.

However I expect that Walter would tell me that he doesn't want to
implicitly create a D interface vtable for every class derived from 
A.
I don't think interfaces should be created implicitly. I think if you want to change the interface, redeclaring it makes perfect sense. This is analogous to the "inserting a call to super" thread. I don't think the compiler should be creating new interfaces without the programmer knowing about it. A seasoned programmer would know in any event with some investigating. But isn't it just as easy to say to the newbie: "you want to change the interface? redeclare it for the derived class. nothing going on behind the scenes. You want to reference a particular version of the interface you do this: (interface)(class) reference. You want the most derived interface? Manipulate interface references directly; don't cast through a base class first." Having said this. I would like to know from Walter how much work it is to generate "implicit" interfaces every time you overload a base classes declared interface. And, how we would refer to these (so as to pass to external apis) if they are implicit.
I'm cool with all of that, except that it appears that I have no way to access most-derived interfaces in the current implementation. I asked point blank about the example in the documentation that states that: (D)b.foo; // calls A's implementation That is wrong to me on so many counts that I can't even begin to talk coherently about it. My major complaint is that A was not mentioned anywhere at all in that code, and B has a valid override of the D interface. If the above statement is true, it is impossible for me to ever make a generic container via interfaces -- the standard polymorphic example of drawable objects leaps to mind. Walter stated clearly that the documentation was correct. I cannot envision how I should understand this system. Sorry, gotta go to a teleconference... Mac
Oct 08 2002
next sibling parent Joe Battelle <Joe_member pathlink.com> writes:
I'm cool with all of that, except that it appears that I have no way to access
most-derived interfaces in the current implementation.
Not true. See below.
I asked point blank about the example in the documentation that states that:

(D)b.foo; // calls A's implementation

That is wrong to me on so many counts that I can't even begin to talk coherently
about it.  My major complaint is that A was not mentioned anywhere at all in
that code, and B has a valid override of the D interface.
It does not have a valid override. That is the whole point! Walter let overrides cover interface methods without requiring redeclaring interfaces and that causes loads of trouble. If he had not allowed the override, then B would _necessarily_ have had to redeclare D to overload foo and (D)b.foo would indeed call B's D. So as long as you manipulate D's without casting through bases you always get most-derived semantics.
Oct 08 2002
prev sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
I asked point blank about the example in the documentation that states that:

(D)b.foo; // calls A's implementation

That is wrong to me on so many counts that I can't even begin to talk coherently
about it.  My major complaint is that A was not mentioned anywhere at all in
that code, and B has a valid override of the D interface.  If the above
statement is true, it is impossible for me to ever make a generic container via
interfaces -- the standard polymorphic example of drawable objects leaps to
mind.

Walter stated clearly that the documentation was correct.  I cannot envision how
I should understand this system.

Sorry, gotta go to a teleconference...
Mac
OK, I'm back from the teleconference. The only mental model I can come up with is that (D)b tries to "cast" b to a D reference, which it can't do (no implementation for D, since it is just an interface). So, it casts it to the nearest thing it can find along that chain, which is A. I can (sort of) buy that from an implementation standpoint. Unfortunately, it completely breaks polymorphism on interfaces, and that raises a consistency issue, because polymorphism works for classes but not for interfaces: class BASE {} interface INTERFACE {} class ONE:BASE, INTERFACE { int foo() {return 1;} } class TWO:ONE, INTERFACE { int foo() {return 2;} } BASE b1, b2; INTERFACE i1, i2; ONE one; TWO two; one.foo(); // returns 1 two.foo(); // returns 1 b1 = (BASE)one; b2 = (BASE)two; i1 = (INTERFACE)one; i2 = (INTERFACE)two; b1.foo(); // returns 1 b2.foo(); // returns 2, as I would expect i1.foo(); // returns 1 i2.foo(); // returns 1, because it uses ONEs implementation rather than TWOs. I'm OK with all of the above except for the last line, which seems completely wrong to me. But I have been assured that that is what would happen. It is equivalent to the code from the documentation that does: (D)b.foo(); // returns 1 from A's implementation D has been replaced by INTERFACE, and b has been replaced by 'two', to avoid confusion with the BASE class. If you make those substitutions, the doc code becomes: (INTERFACE)two.foo(); My code merely uses a storage reference variable, so that what I exactly say is: INTERFACE i2; i2 = (INTERFACE)two; i2.foo(); We can, of course, remove the b1/b2/i1/i2 references, and just do the casts inline, but I expect the problem to arise in real world code when an object reference has been implicitly cast due to a function call and is being stored in a variable reference of a base type (standard collection design). While I can sort of buy the argument that an explicit cast like: (ONE)two.foo(); // returns 1, because it has been case to a one will call the lower interface because of the explicitness of the cast, I don't like that behavior when the cast is implicit. Nor do I like different behavior for implicit vs. explicit casts. And I don't really buy it even for explicit casts, because that wasn't my intent. I wanted to call a function that existed in the ONE class, but I wanted the behavior that was appropriate to the object I actually called it on -- two, of class TWO. That is what polymorphism is for, and it works for classes. Having it _not_ work for interfaces seems like a very inconsistent and error prone design. Realistically, there is no reason for the explicit cast as shown, unless it is meant to be something like C++'s dynamic_cast. I seem to be wandering from my point, sorry... I don't understand why you would _want_ to call a base class's implementation of an interface member. The base class is virtually guaranteed not to properly understand the derived class. If it did, it seems like you wouldn't have overridden that member. However, there is a lot of programming out there that I am unfamiliar with, so I won't state that you never need to do this. I would claim that doing so is an exceptional case, where the programmer is very deliberately choosing a base implementation. As an exceptional case, I think it deserves the special syntax, and common syntax should support polymorphism properly, like it does for classes. Two thoughts for how to access base class implementations: b.A::foo(); // from C++, more or less b.(A)foo(); // from my fevered imagination, as far as I can tell b.(A.foo)foo(); // seems redundant... b.(A.foo)(); // kinda fugly I have no clue how hard the second option would be to parse, either for compilers or for humans. I prefer it over (A)b.foo simply because the mechanism that supports (A)b.foo is the standard reference cast mechanism, and I don't want it to do this for all of the previous reasons. The second option casts the member, not the reference. Of course, syntactically, you are telling it to cast a function into a class reference, which breaks the syntax==semantics rule, which led me to the third option. However, the third option is quite verbose, and suggests that it would be legal to do: b.(A.bar)foo(); which would call A.bar, which raises the question of why foo() is even present -- hence option 4. Really, the only option of those that I like is the first one, but it does bring back the evil C++ scope resolution operator. Oooh! oooh! oooh! (Sorry, just had a potential brainstorm) How would: b.A.foo(); be? Treat each interface as an implicit member. If you are trying to get to a particular interface on an object, you go to that member. If you want standard "most derived" semantics, you just call it normally: b.foo(); // calls B's foo() b.B.foo(); // also calls B's foo(), should you wish to be verbose b.A.foo(); // calls A's foo() b.D.foo(); // illegal - D has no implementation, and thus is not included in // the "pseudo-member" set of base classes. In COM terms, that would mean you got things like: MySurface.DX7_SURFACE.blit(,,,); And because it goes through the member system, you can even use 'with' to gather up a collection of calls that all go through a specific base interface: with MySurface.DX7 { blit(,,,); } vtables/interfaces would not have to exist as specific entities at every level of the hierarchy, and classes that do not provide an overridden implementation would not be considered pseudo-members: // forgive the shorthand, but this hopefully will make sense in the context // of what we have been discussing: interface I class A:I class B:A,I // provides special overrides class C:B // nothing added/changed here class D:C,I // provides special overrides D d; d.foo; // OK, uses D d.D.foo; // OK, uses D d.C.foo; // illegal -- C does not provide specialized implementation d.B.foo; // OK, uses B d.A.foo; // OK, uses A Would such a system meet all of the requirements for everybody? 1. Polymorphic, "most derived" semantics for all common syntax, whether classes or interfaces. 2. Access to specific interface implementations when necessary, in a clear, understandable, and convenient way 3. (Reasonably) easy to implement in a compiler 4. (Reasonably) easy to explain to new programmers It seems like it would to me, but I am biased. Mac
Oct 08 2002
next sibling parent Mac Reiter <Mac_member pathlink.com> writes:
Sorry - while I was typing up my monster length followup, Joe Batelle clarified
an issue for me (that the only reason (D)b.foo fell back to A.foo was because B
did not state that it was overriding the D interface, so b.foo is apparently
part of B, but not part of the D interface to B)

Given that, I pitch my vote in on the "you have to state inheritance from the
interface to override any of its methods".

Although I still like the suggestion I ended up with at the end of the
mega-post... (using "pseudo-members" for base interfaces, so that you would do
b.A.foo() if you actually wanted access to A's foo())

Isn't asynchronous communication wonderful?
Mac
Oct 08 2002
prev sibling parent Joe Battelle <Joe_member pathlink.com> writes:
The only mental model I can come up with is that (D)b tries to "cast" b to a D
reference, which it can't do (no implementation for D, since it is just an
interface).  So, it casts it to the nearest thing it can find along that chain,
which is A.
See my other (parallel) reply to your first post. This stems from allowing covering. When B is forced to redeclare the interface, then this all goes away.
Oct 08 2002
prev sibling parent reply Patrick Down <pat codemoon.com> writes:
Joe Battelle <Joe_member pathlink.com> wrote in
news:antvhr$17e7$1 digitaldaemon.com: 

 First, having one hierarchy declare multiple, yet similar interfaces
 is a mess. If the public interface hasn't changed, then it's much
 better if we can continue to declare a single interface implemented
 differently at different levels in the inheritance [got the spelling
 right finally =] hierarchy. 
I understand.
 
However I expect that Walter would tell me that he doesn't want to
implicitly create a D interface vtable for every class derived from 
A.
I don't think interfaces should be created implicitly. I think if you want to change the interface, redeclaring it makes perfect sense. This is analogous to the "inserting a call to super" thread. I don't think the compiler should be creating new interfaces without the programmer knowing about it. A seasoned programmer would know in any event with some investigating.
I don't think this behaviour is as unexpected as the "inserting a call to super" behaviour. I look at an interface as an inheritable attribute of a class. If I say class Foo is ISerializable then I expect that Foo and all of it's child classes are ISerializable also. To change the behavior of the ISerializable in a child class I override the serialize function of the interface. I don't think this is unexpected or bad because I already expect to change the behavoir of a child class by overriding functions, does it matter if they are part of an interface or not? However, as I already stated, I don't thnk this is a battle I'm going to win and I can live with redefining the interface for base classes. I just think it redundant.
 But isn't it just as easy to say to
 the newbie: "you want to change the interface?  redeclare it for the
 derived class.  nothing going on behind the scenes.  You want to 
 reference a particular version of the interface you do this:
 (interface)(class) reference.  You want the most derived interface? 
 Manipulate interface references directly; don't cast through a base
 class first." 
Easier said than done. Suppose I have multiple hierarchies of classes. For the purpose of the program I store and manipulate them in a containers that holds the base class type. Now I want to store all of them. I would like to create an I/O object and pass it to the containers ISerialize interface. The container in turn will call the ISerialize on all is objects. I think this is a fairly common design pattern but it won't work with interfaces the way they are now.
 
 Having said this.  I would like to know from Walter how much work it
 is to generate "implicit" interfaces every time you overload a base
 classes declared interface.  And, how we would refer to these (so as
 to pass to external apis) if they are implicit.
 
 
 
Oct 08 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
However, as I already stated, I don't thnk this is a battle I'm going
to win and I can live with redefining the interface for base classes.
I just think it redundant.
Don't give up! There's hope--for I feel the same way <g>.
classes.  For the purpose of the program I store and manipulate 
them in a containers that holds the base class type.  Now I want
to store all of them.  I would like to create an I/O object
and pass it to the containers ISerialize interface.  The container
in turn will call the ISerialize on all is objects
I actually think a better way of doing it is to have a DataModel object aggregate all objects you want to serialize by holding interface references to all those differently-inherited objects. To serialize you iterate over this list and you automatically get most-derived semantics. You get your polymorphism without hassle, albeit (possibly) at the cost of another container. In my own real-world experience, I usually have an object represent a file, and this object naturally aggregates all objects that I want to serialize. These interface references are most-derived because they are registered by the constructor of the serializable object.
I think this is a fairly common design pattern but it won't work
with interfaces the way they are now.
Yes it will, but requires your collections be based on utility (interface) rather than kind (base class). I think this leads to better encapsulated design but YMMV.
Oct 08 2002
parent reply Patrick Down <pat codemoon.com> writes:
Joe Battelle <Joe_member pathlink.com> wrote in
news:anv2ir$2fd1$1 digitaldaemon.com: 
 In my own real-world experience, I usually have an object represent a
 file, and this object naturally aggregates all objects that I want to
 serialize.  These interface references are most-derived because they
 are registered by the constructor of the serializable object.
 
I think this is a fairly common design pattern but it won't work
with interfaces the way they are now.
Yes it will, but requires your collections be based on utility (interface) rather than kind (base class). I think this leads to better encapsulated design but YMMV.
This is the problem with giving specific examples. We could ask 14 other programmers and get 14 other answers about how this particular example could be done. I can see that keeping collection of interfaces by utility will work but I don't think that it is always an appropriate solution. So it boils down this, which is my own personal opinion about how things should work. Without any other contextual information I should be able to ask an object if it provides interface X and there should be one and only one implementation of X for that object instance.
Oct 08 2002
parent "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92A18FB0822A7patcodemooncom 63.105.9.61...
 Without any other contextual information I should be able to ask an
 object if it provides interface X and there should be one and only
 one implementation of X for that object instance.
I tend to agree, and that is the current way it works. I don't have a lot of experience using interfaces, so I'm willing to listen <g>. (Note that although it behaves as if there is only one implementation of an interface no matter how many times it is inherited from, the actual implementation provides multiple implementations, each with its own vtbl[] with the right adjustor thunks. This is necessary to make COM work right.)
Oct 09 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:antj7j$que$1 digitaldaemon.com...
 I think it really depends on what people want to use interfaces for.  I
want to
 use them to interface to external programs, or as OS calls/callbacks (a la
 OSKIT) in an embedded system.  This requires multiple, predictable
interface
 definitions at the same time--exactly what we have.
The way it is now is the most derived implementation of a member foo overrides the foo of every interface in the inheritance heirarchy.
Oct 09 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
The way it is now is the most derived implementation of a member foo
overrides the foo of every interface in the inheritance heirarchy.
As in right now. You just changed this in the current release. Without notice I might add. But I can get over it.
Oct 09 2002
next sibling parent Mac Reiter <Mac_member pathlink.com> writes:
In article <ao2c3a$2pvc$1 digitaldaemon.com>, Joe Battelle says...
The way it is now is the most derived implementation of a member foo
overrides the foo of every interface in the inheritance heirarchy.
As in right now. You just changed this in the current release. Without notice I might add. But I can get over it.
Joe, Is it the loss of access to specific base interface implementations that is a problem? I made the following suggesting in a previous post, but I did a fair amount of rambling prior to it, and it may have been missed. How would it be to have syntax that let you access a specific base interface implementation as a member of the object: interface D{int foo()} class A:D {int foo(){return 1}} class B:A,D{int foo(){return 2}} B b = new B; printf("%d\n", b.foo()); // prints 2 printf("%d\n", b.B.foo()); // also prints 2, but probably never used // since you can just do b.foo() printf("%d\n", b.A.foo()); // prints 1, from the A implementation printf("%d\n", b.D.foo()); // compile error, no implementation named D // member syntax/semantics allows grouping use of a specific implementation // using 'with' with b.A { printf("%d\n", .foo()); // prints 1, from the A implementation } This is somewhat like how I understand the COM system to work, but with (at least in my opinion) a prettier syntax. As I understand it, COM would do it something like this: b.GetInterface(UUID_FOR_A)->foo(); And, since GetInterface is a runtime issue, you have to worry about getting back NULL or InvalidInterface at runtime, so you can't just write the code like that. If D built it into the language, it could perform compile time checks to validate the interface use. I would only allow use of base interface implementations. I would not allow someone to use this syntax for using a "reference to D" to get to an "interface implemented in B": D d = <reference to a B object that came from somewhere else> d.foo(); // uses B.foo, because of "most derived" semantics, which I like d.B.foo(); // compiler error -- cannot be checked at compile time d.A.foo(); // compiler error -- same reason If it is necessary to get to a "more derived specific implementation" of an interface (like in d.A.foo()), then some form of dynamic cast or dynamic interface retrieval will be needed. Said mechanism must have some way to signal failure cleanly. Oh, and if the inheritance hierarchy included another class that did _not_ implement the interface, it would be a compiler error to try to use that specific implementation: interface D{int foo()} class A:D {int foo(){return 1}} class A_and_some:A{} // does not do anything to A's implementation of D class B:A,D{int foo(){return 2}} B b = new B; printf("%d\n", b.A_and_some.foo()); // compile error - no such implementation Sorry if this just isn't desired or isn't workable. I didn't see any responses at all to the previous post, so I didn't know if it just got lost in the shuffle or if it was so bad as to not deserve comment. Hopefully it wasn't the latter... Mac
Oct 10 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:ao2c3a$2pvc$1 digitaldaemon.com...
The way it is now is the most derived implementation of a member foo
overrides the foo of every interface in the inheritance heirarchy.
As in right now. You just changed this in the current release.
Yes.
  Without notice
 I might add.  But I can get over it.
It's in the changelog that the semantics were changed. Sorry I wasn't more specific, but the current semantics seems to be the most defensible.
Oct 10 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
It's in the changelog that the semantics were changed. Sorry I wasn't more
specific, but the current semantics seems to be the most defensible.
I know, I was just being cranky. I was serious though. You have a pattern of going quiet, implementing what you think is best and then throwing it out to the group. Some may find this a good thing. It's certainly reasonable in the sense that D is your thing and you're putting in the effort. What bothered me about this last round is that I spent some of my overcommitted time debating/discussing interfaces at the same time that you were implementing them in a way completely opposite of what I was proposing. You can choose any implementation you like, but it's not cool to give the impression that the debate is still open and then drop a bombshell indicating it's not because you implemeted something else. I have used up the free time I have allocated to interfaces for now, so I will leave it to the rest of the group to explore.
Oct 11 2002
parent "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:ao8ddr$2vlu$1 digitaldaemon.com...
 I know, I was just being cranky.  I was serious though.  You have a
pattern of
 going quiet, implementing what you think is best and then throwing it out
to the
 group.  Some may find this a good thing.  It's certainly reasonable in the
sense
 that D is your thing and you're putting in the effort.  What bothered me
about
 this last round is that I spent some of my overcommitted time
 debating/discussing interfaces at the same time that you were implementing
them
 in a way completely opposite of what I was proposing.  You can choose any
 implementation you like, but it's not cool to give the impression that the
 debate is still open and then drop a bombshell indicating it's not because
you
 implemeted something else.  I have used up the free time I have allocated
to
 interfaces for now, so I will leave it to the rest of the group to
explore. Your ideas and input here have been extremely valuable and I appreciate immensely the effort you've put into your posts. Picking the correct semantics for interfaces is certainly a confusing exercise. You are the one who originally discovered that what I had implemented was completely broken. You were quite right. I plead guilty to going quiet for a while, sometimes that is because I am working on another problem and I prefer to do only think about one thing at a time. Although it may appear that the debate is closed because I've implemented something else, since I've reimplemented the interface semantics several times now due to these discussions, I don't think it's true. I put out the new implementation as a strawman model for further discussion. I apologize if I gave the wrong impression here.
Oct 12 2002
prev sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"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?
Oct 03 2002
prev sibling parent "chris jones" <flak clara.co.uk> writes:
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.
Oct 03 2002