Interface implementation name clashes

[Duncan Pearson]

If I wish a type to implement two interfaces developed independently,
and if there is a method in one interface for which a method with the
same name exists in the other interface then I potentially have a
problem.

In the unlikely event that the intended behaviour of the method is the
same in both interfaces then I am OK. If not however there are two
possibilities. Either the signature is the same, in which case in my
implementation I am left with the problem of knowing whether I am
being called as an instance of Interface1 or of Interface2 or simply
of MyType. As far as I can see there is no way of telling. If the
signature is different then I simply cannot implement both.

A related problem is that in a system under development, in which the
definitions of interfaces might change, I have no way of ensuring that
a type implements a given interface as the compiler does not know that
it is intended to. It is not until an instance of the type is used for
an instance of the interface that the compiler will check.

Would it be possible to have an interface implementation declaration
for a type. If so might it be possible to augment this with a map from
the names of any interface functions to the functions (or names of the
functions) that implement them.

Neither of these things would need to be used and so would not detract
from the ease of use of the system, but if implemented they would add
flexibility and manageability to large systems.

e.g.

implementation MyType ; Interface1 {
foo : myFoo;
goo : myGoo
}

[Eugene O'Neil]

On Wed, Nov 25, 2009 at 4:48 AM, Duncan Pearson <ma...@duncanpearson.net> wrote:
> If I wish a type to implement two interfaces developed independently,
> and if there is a method in one interface for which a method with the
> same name exists in the other interface then I potentially have a
> problem.

Does ANY language have an explicit mechanism allowing one object to
satisfy two different interfaces that expect one method to do two
different things? Java and C++ certianly do not.

And wait a minute, Is there any plausible, practical reason it has to
all fit in ONE object? Just write two objects.

> A related problem is that in a system under development, in which the
> definitions of interfaces might change, I have no way of ensuring that
> a type implements a given interface as the compiler does not know that
> it is intended to. It is not until an instance of the type is used for
> an instance of the interface that the compiler will check.

You WILL get a compiler error if you try to assign a concrete data
type directly to an interface it does not satisfy. It's only a runtime
error if you're doing fancy tricks with the empty interface, and then
you deserve what you get.

> Would it be possible to have an interface implementation declaration
> for a type.

Of course it's "possible" to re-implement java, but we already have Java.

> If so might it be possible to augment this with a map from
> the names of any interface functions to the functions (or names of the

> functions) that implement them. (...)

> e.g.
>
> implementation MyType ; Interface1 {
>    foo : myFoo;
>    goo : myGoo
> }

Not even C++ has implemented such a baroquely over-engineered solution
to the fundamentally social problem of development teams not talking
to each other, and their implementation of templates are Turing
complete.

And really, it isn't any SIMPLER than just writing another object that
implements the interface. In fact, if it was implemented at all (and I
hope it isn't) it would probably just be syntactic sugar for
boiler-plate code you could write yourself:

func (p *MyType_Interface1) foo() { p.myFoo(); }

[SnakE]

2009/11/26 Eugene O'Neil <eugene...@gmail.com>

On Wed, Nov 25, 2009 at 4:48 AM, Duncan Pearson <ma...@duncanpearson.net> wrote:
> If I wish a type to implement two interfaces developed independently,
> and if there is a method in one interface for which a method with the
> same name exists in the other interface then I potentially have a
> problem.

Does ANY language have an explicit mechanism allowing one object to
satisfy two different interfaces that expect one method to do two
different things? Java and C++ certianly do not.

Certainly not.

#include <stdio.h>
struct A {
    virtual int get() = 0;
};
struct B {
    virtual int get() = 0;
};
struct AB : A, B {
    virtual int A::get() {
        return 1;
    }
    virtual int B::get() {
        return 2;
    }
};
int main() {
    AB ab;
    printf("A: %d, B: %d\n", ((A*)&ab)->get(), ((B*)&ab)->get());
    return 0;
}

[Duncan Pearson]

On Nov 25, 10:09 pm, "Eugene O'Neil" <eugene.on...@gmail.com> wrote:
> Does ANY language have an explicit mechanism allowing one object to
> satisfy two different interfaces that expect one method to do two
> different things? Java and C++ certianly do not.

C# allows you to do this although it is so long since I did any that I
can't remember the exact details.

Again it is not one method, it is two. They just happen to share a
name. Furthermore a name over which I as owner of neither interface
have any control.

[Jessta]

On 25/11/2009, Duncan Pearson <ma...@duncanpearson.net> wrote:
> Would it be possible to have an interface implementation declaration
> for a type. If so might it be possible to augment this with a map from
> the names of any interface functions to the functions (or names of the
> functions) that implement them.

Go specificly doesn't do this. You don't implement interfaces in Go,
you write functions for the functionality of your objects. Once you
have the object functionality written you can pull out an interface
from the package that matches a number of objects you've written so
that developers can more easily make use of your code.

This is very unlike java, where an 'architect' might write up
interfaces first and then hand the interfaces off to lowly coders to
be implemented. Which leads to things like methods that don't make
sense for an object but are there so that an object can be said to be
implementing a specific interface.

If you're coming up against a problem of having an object that needs
to do two different things with the same method name then you should
rethink your design

- jessta

--
=====================
http://jessta.id.au

[Ben Tilly]

On Wed, Nov 25, 2009 at 2:09 PM, Eugene O'Neil <eugene...@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 4:48 AM, Duncan Pearson <ma...@duncanpearson.net> wrote:
>> If I wish a type to implement two interfaces developed independently,
>> and if there is a method in one interface for which a method with the
>> same name exists in the other interface then I potentially have a
>> problem.
>
> Does ANY language have an explicit mechanism allowing one object to
> satisfy two different interfaces that expect one method to do two
> different things? Java and C++ certianly do not.

AFAIK Java does. Java lets you have 2 methods with the same name and
different types, which would let you satisfy two interfaces that
expect you to have a method of the same name, but with different
types.

At least this is my understanding. But I am not a Java developer.

Cheers,
Ben

[gorgo...@online.de]

i think that interface name clashes only occur if the mixed-up interfaces are badly designed or from very unrelated packages. otherwise the packages are trimmed to not clash or they themselves inherit and export sanely so that there is no further need. the question is how much of *fiddling* a language should allow. in other words: how much freedom of mixing up interfaces should be supported? i think that most related languages work fine without too much of freedom in this respect. also, one can circumvent interface clashes by putting an *abstraction* (some methods using the interfaces separately and bundled to a new type, for example) between them and a new interface. ok, this causes redundant propagation.

gorgonzola

[Marcin 'Qrczak' Kowalczyk]

2009/11/26 Ben Tilly <bti...@gmail.com>:

>> Does ANY language have an explicit mechanism allowing one object to
>> satisfy two different interfaces that expect one method to do two
>> different things? Java and C++ certianly do not.
>
> AFAIK Java does.  Java lets you have 2 methods with the same name and
> different types, which would let you satisfy two interfaces that
> expect you to have a method of the same name, but with different
> types.

AFAIK C# does even in case the signatures are the same (the method
name needs to be qualified with the interface name).

--
Marcin Kowalczyk

[ziyu_huang]

A good programming language should help programmer reduce unecessary
type and provide elegant solution.
But it's not help programmer solve stupid design. Provide a default
solutiion to *work around* a poor design is a bad thing I think. A
good lanaguage should sometimes forbidden programmer do stupid, I
think this is one of the case. If your modeling is poorly define two
kind of behavior with simliar interface , is it correct that your
implementation mix this two interface ? You should review your design
not review the language support.

[Dennis Heuer]

did you target at me? as far as i understand your arguments, we are in
line. however, some stupid designs of other developers may force you to
work around with an abstraction. this is why i mentioned that. i don't
propagate it.

as far as i understand the art of interfacing, those conflicts can be
circumvented if all higher interfaces only base on lower interfaces but
not on other types. this allows the other types to implement those lower
interfaces and become compatible with the higher interfaces. that way,
one doesn't need two interfaces with same definitions. the only problem
is that a function then might try to write a string into an int or so.
but it can catch the error, and this is what it should rely on - not
deeper knowledge into types and interfaces. am not sure if this can be
circumvented in all cases. possibly we need a good tutorial about
interfaces that shows how well one can design an interface hierarchy
without any clashes or ambivalences. yet, i can't see any clashes or
ambivalences that are not introduced by the design of the developer.

--
GorgonZola <gorgo...@online.de>

[Peter Froehlich]

Hi all,

[Sorry, vacationing in Palm Springs :-)]

I brought this up before because Lagoona (our language that had the
same interface type structure) used modules/packages to resolve that
problem. I don't think the Go guys can "go" that route though without
strengthening the module/package construct. In practice it's probably
not much of an issue, but *theoretically* in the component systems we
targeted with Lagoona, the problem is a total deal breaker: you can't
have component systems unless you can guarantee that name clashes
(whether syntactic or semantic) don't happen. But like I said, that's
theoretical stuff you do for a PhD, I doubt it's going to matter much
for Go.

Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Russ Cox]

On Wed, Nov 25, 2009 at 01:48, Duncan Pearson <ma...@duncanpearson.net> wrote:
> If I wish a type to implement two interfaces developed independently,
> and if there is a method in one interface for which a method with the
> same name exists in the other interface then I potentially have a
> problem.

Yes, you do.

> In the unlikely event that the intended behaviour of the method is the
> same in both interfaces then I am OK. If not however there are two
> possibilities. Either the signature is the same, in which case in my
> implementation I am left with the problem of knowing whether I am
> being called as an instance of Interface1 or of Interface2 or simply
> of MyType. As far as I can see there is no way of telling. If the
> signature is different then I simply cannot implement both.

Indeed, but then it was probably a mistake to use the same
method name for two different meanings. The fix is to rename
one or both of them to make the clash go away.

Interfaces are programming by convention, which is very flexible
and very powerful but does require adhering to conventions.
One of these is to use different names or type signatures for
different behaviors.

This is a simplifying assumption in the design of Go and in
programs written using Go. By forcing you to structure
your program differently rather than make the language more
complex, Go avoids the burden of added complexity in
the language and in the runtime. Every such simplifying
assumption has to be balanced against how hard it is to
program in the simplified model, but in our experience, it has
not been difficult to arrange that different meanings use
different method names, and our programs are clearer for it.

Russ

[ma...@duncanpearson.net]

Thanks Russ,

The trouble I am anticipating comes in the circumstance that I as the developer of the implementation have no control over either interface, both of which have been developed elsewhere in different organisations.

I am aware that declaration of interface implementation also carries with it a requirement to bind to the package containing the interface being implemented. To avoid circularity it might be necessary to define interfaces in a separate package, rather like a C header file, and I can see that you are trying to avoid that.

Furthermore I can see that it would be possible to produce fairly lightweight generic interface implementation redirectors, that would work in a way similar to COM aggregation, and that this is probably how I would go in this circumstance.

Thank you all for your advice.

[smosher]

On Nov 29, 1:12 pm, Russ Cox <r...@golang.org> wrote:
> Interfaces are programming by convention, which is very flexible
> and very powerful but does require adhering to conventions.

To this end I would go so far as to focus on interfaces in the
generated documentation. Learning the interfaces is critical in most
of the interesting packages, and presently it's not obvious what you
are looking for until you have actually found it. Exposing the
interface details prominently should help avoid mistakes like creating
methods that conflict with convention. (I'm not sure what the exact
presentation should be. I've been meaning to give it some thought.)

[mythz]

C# does let you do this if the method signature doesn't match out of
the box.
You can also go one step further and provide different implementations
for each interface with the same signature using 'Explicit
Interfaces':

public class A
: IA, IB
{
int IA.Join(int a, int b)
{
return a + b;
}

int IB.Join(int a, int b)
{
return a * b;
}
}

public interface IA
{
int Join(int a, int b);
}

public interface IB
{
int Join(int a, int b);
}

But if you came across this problem in practice than the easiest thing
to do with a language that doesn't support it is to create a Wrapper
adapter class containing the implementation of one of them while
exposing the same signature of the other one.


On Dec 1, 9:52 am, "m...@duncanpearson.net" <m...@duncanpearson.net>
wrote:

[gorgo...@online.de]

actually, it looks somehow wrong to me that interfaces are defined in
packages of specific content though they shall be implemented widely.
yes, the idea for an interface stems from a certain package, but that
is only a pragmatic relation because interfaces are subject-neutral
contracts - at least they should be, or am i wrong here? if go were
consequent, it would expect interfaces in an own file-hierarchy. there
are practical issues with this approach but ... only for having it
said...


--
GorgonZola <gorgo...@online.de>

[smosher]

On Dec 1, 1:18 pm, gorgonz...@online.de wrote:
> actually, it looks somehow wrong to me that interfaces are defined in
> packages of specific content though they shall be implemented widely.
> yes, the idea for an interface stems from a certain package, but that
> is only a pragmatic relation because interfaces are subject-neutral
> contracts - at least they should be, or am i wrong here? if go were
> consequent, it would expect interfaces in an own file-hierarchy. there
> are practical issues with this approach but ... only for having it
> said...

I agree, it is sort of disproportionate. I guess the idea is that
along with interface adherence being a conventional matter, interface
establishment is just as casual. On one hand it's more logical to
define interfaces outside of packages, but on the other does defining
them along with a given package cause any problems? I suspect not. (Of
course, if it had been decided to define interfaces externally they
would merit their own documentation and the documentation issue
wouldn't exist. I propose that additional documentation be generated
as though this were the case, with the addition of lists of the
implementing (or 'embedding' if you prefer) types. I think it's very
appropriate.)

[gorgo...@online.de]

On Tue, 1 Dec 2009 15:38:35 -0800 (PST)
smosher <dark.n...@gmail.com> wrote:

> On Dec 1, 1:18 pm, gorgonz...@online.de wrote:
> > actually, it looks somehow wrong to me that interfaces are defined in
> > packages of specific content though they shall be implemented widely.
> > yes, the idea for an interface stems from a certain package, but that
> > is only a pragmatic relation because interfaces are subject-neutral
> > contracts - at least they should be, or am i wrong here? if go were
> > consequent, it would expect interfaces in an own file-hierarchy. there
> > are practical issues with this approach but ... only for having it
> > said...
>
> I agree, it is sort of disproportionate. I guess the idea is that
> along with interface adherence being a conventional matter, interface
> establishment is just as casual.

yes, but, if you develop the video package first, you will have to
import some of its interfaces from your audio package or develop
separate versions. i wrote about the bottom-up approach. if this is not
strictly followed, there is no related "lower" package the interfaces
could be pushed in.


--
GorgonZola <gorgo...@online.de>

[yejun]

Is it possible to use switch on interface?

switch this.(type) {
case interface1 :
....

[Russ Cox]

On Tue, Dec 1, 2009 at 14:58, yejun <yej...@gmail.com> wrote:
> Is it possible to use switch on interface?
> switch this.(type) {
> case interface1 :

Yes.

Instead of sending an email to 2000 people,
you could have written a simple test program.

Russ

[smosher]

On Dec 2, 8:17 am, gorgonz...@online.de wrote:
> > I agree, it is sort of disproportionate. I guess the idea is that
> > along with interface adherence being a conventional matter, interface
> > establishment is just as casual.
>
> yes, but, if you develop the video package first, you will have to
> import some of its interfaces from your audio package or develop
> separate versions. i wrote about the bottom-up approach. if this is not
> strictly followed, there is no related "lower" package the interfaces
> could be pushed in.

That is a good example to bring up. How I would deal with it depends
on the specifics. For example, should the two really overlap in areas
that make sense to define the interfaces in one package or the other,
but not in a more general package that both would import? It's
something I'll be considering.

[Peter Froehlich]

Hi all,

On Wed, Dec 2, 2009 at 6:50 PM, smosher <dark.n...@gmail.com> wrote:
> That is a good example to bring up. How I would deal with it depends
> on the specifics. For example, should the two really overlap in areas
> that make sense to define the interfaces in one package or the other,
> but not in a more general package that both would import? It's
> something I'll be considering.

That's what we're doing with the database bindings. I've put together
a db.go that contains the interfaces and the actual database bindings
import that and implement it. Of course that's not really a solution
in general since you can still have conflicts. But I assume in Go this
will be resolved by emailing the problem to the authors of the
packages involved and getting things resolved that way. In a true
component system you couldn't do that of course.

[Ian Lance Taylor]

Peter Froehlich <peter.hans...@gmail.com> writes:

> On Wed, Dec 2, 2009 at 6:50 PM, smosher <dark.n...@gmail.com> wrote:
>> That is a good example to bring up. How I would deal with it depends
>> on the specifics. For example, should the two really overlap in areas
>> that make sense to define the interfaces in one package or the other,
>> but not in a more general package that both would import? It's
>> something I'll be considering.
>
> That's what we're doing with the database bindings. I've put together
> a db.go that contains the interfaces and the actual database bindings
> import that and implement it. Of course that's not really a solution
> in general since you can still have conflicts. But I assume in Go this
> will be resolved by emailing the problem to the authors of the
> packages involved and getting things resolved that way. In a true
> component system you couldn't do that of course.

If you're really stuck you could write a new struct which renames the
method.

type MyStruct struct {
TheirStruct;
}

func (p *MyStruct) MyMethod() {
p.TheirConflictingMethod()
}

The other methods will be inherited.

Ian