• Post Reply Bookmark Topic Watch Topic
  • New Topic

interface inheritance  RSS feed

 
Swapnil Dharane
Ranch Hand
Posts: 55
Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

I think the topic I am going to start here has probably been discussed many times before but still I have not found the actual answer to the question that has been raised previously.

So the question is as java doesn't support multiple inheritance(let's not consider usage of interfaces here),a class cannot extend more than one class (that is only one immediate superclass) .But this doesn't apply to inteface inheritance.An interface can extend more than one interfaces (more than one immediate parent interfaces).How this can be possible?
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swapnil Dharane wrote:How this can be possible?

I don't quite understand the question, but the simple answer is: because the designers wanted it that way. And since interfaces don't involve code, there's no "diamond problem" to worry about.

Personally, I much prefer it to C++, which allows multiple inheritance as well.

Winston
 
fred rosenberger
lowercase baba
Bartender
Posts: 12565
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When a class has "implements X,Y, and Z", that means that the class guarantees that the methods defined in X,Y, and Z will be implemented. There is no promise of HOW they will be implemented.

So, if both X and Y have a method "public int foo(String A, int x)", you only have to implement it once to satisfy both promises. It's like if a child promises his mother he will mow the lawn, and then promises his dad he will mow the lawn. He only has to mow it once to satisfy both conditions.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As long as he doesn’t promise Mum to mow the lawn 1″ long and Dad he’d mow it 2″ long. The two methods with the same signature ought to have the same intent, and must have the same return type. As for “same intent,” have a look at the add() method in the Collection, List and Set interfaces.
 
Swapnil Dharane
Ranch Hand
Posts: 55
Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But do you really think there will not be dimond problem in case of multiple inheritance of interfaces?
 
Aditya Jha
Ranch Hand
Posts: 227
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swapnil Dharane wrote:But do you really think there will not be dimond problem in case of multiple inheritance of interfaces?

Can you give an example as to why you think there could be a diamond problem in case of multiple inheritance of interfaces?
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have already told you: if the two versions of the method have different intent, there is a diamond problem. Look at the three versions of add() I quoted earlier.
If the two methods have different return types, the compiler cannot distinguish them reliably, and it will fail to compileThat is the only way you are going to get a diamond problem by implementing multiple interfaces.
If you have different return types, you can’t write one method which matches the return types.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swapnil Dharane wrote:But do you really think there will not be dimond problem in case of multiple inheritance of interfaces?

As far as the compiler is concerned, there will be no problem.

The diamond problem comes from inherited behavior. Interfaces merely define what messages can be sent to objects, they don't change what the objects actually are or what they do. In other words, when an object implements one or more interfaces, this doesn't cause it to gain or inherit any behavior; it simply means the object can be sent the messages that are defined by the interface(s) it implements.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem that Campbell points out is a design problem. The compiler doesn't care about that. That's something that developers need to work out. All the compiler sees is that there is a method defined by an interface and any objects that implement that interface should have a method with that signature. If the compiler can't figure out an exact path of execution, it simply generates a compiler error.
 
Swapnil Dharane
Ranch Hand
Posts: 55
Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right Junilu there will be no compilation problem but surely design problem will be there as it may harm the intent of the methods as pointed out by campbell.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swapnil Dharane wrote:You are right Junilu there will be no compilation problem but surely design problem will be there as it may harm the intent of the methods as pointed out by campbell.

Yes, but a language can only go so far. Are you expecting a compiler to somehow divine our intent? All it can see is code, and since the designers didn't see fit to worry about combinations of interfaces that have the same methods (which might be worthy of discussion, but doesn't answer your question - personally, I think it was the right decision), it has nothing to complain about.

Winston
 
Swapnil Dharane
Ranch Hand
Posts: 55
Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
of course Winston !! I am not expecting compiler to understand the intent of programmer and I am not complaining either.That's upto programmer how to design interfaces
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Of course, Campbell has also pointed out circumstances in which the diamond pattern is something that the compiler can and does care about. It's not clear whether anyone else has read and understood this, but the subsequent comments seem to indicate they have not.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:Of course, Campbell has also pointed out circumstances in which the diamond pattern is something that the compiler can and does care about. It's not clear whether anyone else has read and understood this, but the subsequent comments seem to indicate they have not.

I did, but I don't see it as much of a problem, since the class could be abstract and not implement the method at all, and the compiler will still complain (admittedly the message isn't that great though). It seems to me that at that point someone might be smart enough to work out that they have a design issue on their hands.

Winston
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:Of course, Campbell has also pointed out circumstances in which the diamond pattern is something that the compiler can and does care about. It's not clear whether anyone else has read and understood this, but the subsequent comments seem to indicate they have not.

Actually, I did read it several times and I'm pretty sure that my understanding of the problem that Campbell gave in his example is clear. Maybe "the compiler doesn't care about that" wasn't the best way to express my understanding though. What I meant by that was just because the intent noted in the comments (mow 1" vs mow 2") is different, since the method signatures are the same, the compiler is content to see them as the same method. However, since the methods declare different return types, the compiler will still find ambiguity if you implement either or both versions of the method, so it just generates a compile-time error. In this sense, I guess you could say it does in fact care about the problem enough to say that it can't be programmed that way. When the developer sees the error, he/she should recognize it as a design problem.

In contrast, the design and implementation of compilers for languages that support multiple inheritance is much more complex and application design problems may not be immediately obvious because the compiler may still find a way to determine an exact execution path, regardless of whether or not it is in line with the designer's intent. I agree with Winston and others who think that not supporting multiple inheritance in Java was a good decision.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it is not a case of the compiler “caring”. It is only a machine, after all. It is a case of what the compiler can be programmed to do. Reading javadoc comments to understand the intent of a program is most certainly not one of them. There are occasions where a programmer has to demonstrate they actually have something inside their head.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:I think it is not a case of the compiler “caring”. It is only a machine, after all. It is a case of what the compiler can be programmed to do.

Yes, apparently, there just isn't a good way to use anthropomorphism to express what the compiler does...
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with all points about it being fundamentally a design problem; I just disagreed with the repeated claims that it's not a compiler problem. Admittedly it's not usually a compile problem; incompatible return types seems to be a pretty rare thing. But it seemed odd to be making that claim immediately after Campbell's post showing how it could be a compiler problem.

I have little problem with anthropomorphizing the compiler, either. I thought the intent was clear enough.

Cheers!
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think we are going round in circles here, all disagreeing about what we actually agree about.
 
salvin francis
Bartender
Posts: 1664
37
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



CoolBoy is eternally doomed to have a compile time error

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!