Here's an example using multiple interface inheritance in Java and there's an issue.
Note that I fully know why there's an issue and this is not the point of my question. The question is about how you name this particular multiple interface inheritance ambiguity, if there's a name for it.
For example, in C++, the ambiguity that arises when you use multiple implementation inheritance and cannot determine which overridden method to use is called the "diamond problem":
http://en.wikipedia.org/wiki/Diamond_problem
Now once again, I know this is not the same problem here: that's not the point. The point is that a name has been coined in that previous case.
And I'd like to know if a name exists for the issue I'm about to describe.
Here's an example of another kind of multiple inheritance, where one interface inherits from two other interfaces that have an incompatible method return type:
interface A {
void a();
Integer c();
}
interface B {
void b();
Long c();
}
interface MI extends A, B {...}
(notice multiple interface inheritance at work using the 'extends' keyword)
You cannot do that, because:
types A and B are incompatible; both
define c() but with unrelated return
type
Has a name been coined to describe that situation?
I'm not sure there is a specific name for it, or at least it doesn't seem to be very commonly used. It's "just" a problem of the implicit mapping of interface methods to class methods; if you could have overloads which differ in return types only, there would be no problem either. So it comes down to an signature/overloading/implicit method mapping problem.
In the "Thinking in Java" online book, there isn't a name for it either.
http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ310_001.htm
Just a side-note, C# allows explicit interface implementations, which addresses this problem.
JLS §6.4.4, The Members of an Interface Type calls such duplicate superinterface members ambiguous, and requires a compile-time error. I was hoping for something colorful such as the Beaujolais Effect, Heisenbug, et al. Maybe two's-a-crowd?
I also don't know of any specific name for this problem. Whenever it arised it was described in a sentence containing the words return type incompatibility at some point. You could also call it the Map/Set incompatibilty as this is one of the more prominent and annoying examples in the Java class libraries. It makes it impossible to have the same class implement Map as well as Set or Collection just because Map defines a remove(Object) method with a different return type than Collection.
public interface Collection<E> extends Iterable<E> {
boolean remove(Object o);
}
public interface Set<E> extends Collection<E> {
}
public interface Map<K,V> {
V remove(Object key);
}
I'd hesitate to call this a multiple inheritance issue, because interfaces merely describe well, interface--a set of methods an implementing class must define--rather than any implementation. Extending an interface with other interfaces doesn't really mean the subinterface inherits from the superinterface, but rather that the subinterface is, in essence, a concatenation of the methods defined in the two.
If a third interface is used to extend the subinterface and provides a conflicting method declaration, it's essentially the same as if you had just provided the same two conflicting methods in the same interface.
I don't remember if I have ever seen any name for this. In Java Language Specification there is no name for this either.
The issue you describe exists in .NET as well as Java, but has a simple solution there: the .NET framework allows a class to implement an interface member using a class member with a different name. Thus, although the class methods which implement two interface members which differ only in return type are required to have different names, that does not preclude their ability to implement interface members with the same name.
If an interface inherits two interfaces with conflicting members, a class which implements the composite interface may implement the members just as if it had inherited the conflicting interfaces directly. Consumers of the combined interface will generally not be able to use the members of either component interface without a converting the reference to one of the other interface types, but the cast in question will be considered an upcast rather than an downcast.
The scheme implemented in .NET works nicely there. Unfortunately, there's no way to do anything similar in Java. I don't know that Java will squawk if an interface inherits other interfaces with conflicting members, but whether or not it squawks at that point, there would be no way to produce a class which could implement it.
I don't think a name has been defined because interfaces in Java cannot have method implementation, the problem is therefore avoided since there is always only one implementation to a specific method and hence no ambiguity will arise.
Have I missed the point or are you talking about the 'c' variable?
