>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.

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.

"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.

>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.

"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.)

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

"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.

>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.

"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.