#Question about diamond problem

1 messages · Page 1 of 1 (latest)

steel ether
#

I know that a class can't extend from 2 or more classes due to a diamond problem (same method signature in both superclasses).

But when a class implements 2 or more interfaces that both have the same implemented (default) method signatures, you get a compile error.

Why doesn't java allow to extend from 2 or more classes but throw a compile error if they both have the same method signature to avoid diamond problem?

quaint jacinthBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
I know that a class can't extend from 2 or more classes due to a diamond problem (same method signature in both superclasses). But when a class implements 2 or more interfaces that both have the same implemented (default) method signatures, you get a comp

erfaces and those interfaces have the same method signature, there is no diamond problem because interfaces only provide method declarations, not implementations.

In the case of conflicting method signatures in multiple interfaces, the implementing class has to provide its own implementation of the method. This allows Java to avoid ambiguity and the diamond problem that occurs with multiple inheritance in classes.

If a class implements two interfaces with conflicting method signatures, it must provide its own implementation for both methods. This means that there is no conflict or ambiguity in the implementation of methods from multiple interfaces.

Overall, while classes cannot extend from multiple classes due to the diamond problem, they can implement multiple interfaces without running into conflicts as long as they provide their own implementations for any conflicting methods. This allows for flexibility and modularity in Java programming without the issues that can arise from multiple inheritance.

wind kraken
#

so there is nothing preventing java from allowing multiple inheritance

#

the diamond problem doesn't prevent it, its just a problem with it you need to decide what happens with

#

in python this is done through its MRO algorithm

#

but its arguable that no good solutions exist

#

you can find interviews with the original java devs where they state their reasoning, but its basically just "ugh what a nightmare"

#

the difference between interfaces and classes here is that interfaces cant have fields or constructors

#

so its an easier problem to deal with

steel ether
#

well interfaces can have fields, and you get compile time error if you define same field in 2 interfaces that are implemented by same class.

#

For constructors I agree, it wouldn't know which one to run

wind kraken
#

they can have methods

#

and yeah that is a problem

#

you are correct that interfaces also lead to "the diamond problem"

#

its just less of a problem with them

steel ether
#

public/static/final fields are allowed in interfaces

wind kraken
#

sure, but no instance fields

#

thats the difference

steel ether
#

hmm how is it called if not instance field?

wind kraken
#

its a static field

#

attached to the class

#

but yeah you aren't wrong, interfaces still have problems

#

they have fewer problems than regular classes though

#

hence why one is allowed and the other isn't

spiral igloo
#

if you wanna look at the diamond problem, default methods would be the approach

wind kraken
#

not much deeper than that

spiral igloo
#

"understanding which implementation to use" is the core of the problem

wind zenith
#

I wonder even if default methods are supported in Interfaces, how often do people really define default methods? Cause that might cause problems

steel ether
#

thanks @wind kraken I think I understand, its just to prevent from causing more headaches and problems

south canyon
#

it's not the same thing with classes

#

classes have fields

#

and fields have a specific offset from the object header

#

so java knows at which offset it needs to go to fetch the field

#

and while this is not really specified in the language spec and JVM is free to implement memory as it sees fit, implementing multi inheritance would be a huge pain in the ass and likely come with a performance hit

#

or some other stupid thing like generating extra classes at compile-time

spiral igloo
#

inheritance has been losing its mojo for a while now

#

"prefer composition over inheritance" is the new trend

#

this is just a step toward that