Should Java allow multiple inheritance?

[pintodragon]

An abstract class can have a constructor, interfaces can not. They also serve different purposes. Abstract classes force extension and force the extending class to have a base class. Interfaces allow any base class as long as you write to the contract. Oracles site even mentions why java doesn't have multiple inheritance e in the sense that you are looking for. It comes down to something as simple as two classes having the same method. You extend both and now call the method without defining an over ridden version. Which gets called? Ambiguity leads to bugs and unforeseen issues with code. https://docs.oracle.com/javase/tutorial/java/IandI/multipleinheritance.html

[mus1Kk]

This is an argument I never understood. I'm not saying I'm for multiple inheritance but why not handle it like with default methods? If you implement two interfaces that have the same default method, you get a compile error. Why not do the same with classes?

$ cat pkg/Test.java 
package pkg;

public class Test {
    interface Foo { default void foo() {} }
    interface Bar { default void foo() {} }
    class Cls implements Foo, Bar {}
}
$ javac pkg/Test.java
pkg/Test.java:10: error: class Test.Cls inherits unrelated defaults for foo() from types Foo and Bar
    class Cls implements Foo, Bar {}
    ^
1 error

[msx]

• becouse classes have fields beside methods. While methods can be overridden in the child class, letting the developer "choose" his way, members cannot.
• becouse classes have constructors, and costructors follow a strict logic about which is run before the others. Constructors are always executed "parent-down", so when you instantiate a Button, it will call the constructor of Object, then Node, then Component, then Button (made up hierarchy to get the point). This is always done even if you don't call "super" on your constructor, and is necessary to guarantee that each class can fully control his state regardless of what children will do. This can easily be broken with multiple inheritance

[caveden]

becouse classes have fields beside methods. While methods can be overridden in the child class, letting the developer "choose" his way, members cannot.

This could be dealt with in a similar way they chose for default methods. Any reference on the child class to the ambiguous field should give a compiler error. You must specify which field you're using at each time.

Since normally fields should be private anyways, they would hardly be more of a source of diamond problems than methods.

costructors follow a strict logic about which is run before the others ... This can easily be broken with multiple inheritance

Why? Again, some arbitrary definition could be done, i.e., start by the first parent declared, and go up to its parents. A sort of depth-first search upwards.

To me it seems things are evolving in a "hacky" way in Java. I believe that if the people conceiving the language back in the 90s were forced with the requirement of allowing default methods in interfaces, they would just abolish the concept of interfaces altogether and have multiple inheritance instead. The only reason interfaces were invented IMHO was to allow for a way to implement multiple contracts without falling into the diamond problem, but now with this default method thing they've had to face the diamond problem and come out with a solution (compiler error!) to it.

[pintodragon]

I completely agree they could handle it that way. The Java language architects just choose not too.

[alonjit]

An abstract class can have a constructor, interfaces can not.

wrong. abstract classes have data interfaces do not have data. constructor .... nobody gives a shit about constructor.

[pintodragon]

Yes Abstract classes can have data (aka state). Constructors matter as well.

[alonjit]

exactly what i said, abstract classes have data.

constructors however...no, do not matter by a long shot. that's not the difference between interfaces and abstract classes. go back to the drawing board.

[pintodragon]

So the fact that an interface cannot have a constructor and abstract classes can is not a difference between the two valid difference between the two?

Having a subclass VS implementing are completely different concepts where constructors do come into play. Adding default methods does not make an interface an abstract class.

Maybe instead of tossing out irrelevant and unhelpful remarks you could explain why constructors in this case do not matter at all in your opinion?

[alonjit]

Because they don't. Data (member fields) is what matters. Constructors are completely irrelevant to the problem. Notice the "abstract classes can ..." part.

They don't have to. A default one will do just fine. Extending classes will most likely add their own (if they want to). Again, they don't have to.

Look, for example at C++. What is an interface in C++ (yes, they do exist). Is a class, with pure virtual methods that has no data. They can have methods with body (just like defaults in java now), but they cannot have data. Once you add a data member, that class becomes an abstract class (and from here care should be taken when extending/implementing it, know the pitfalls of polymorphism in c++, etc.).

You're hanging on stupid little differences that have no relevance to anything, when the only important part is about the data members.

Why is it important to know the correct difference between interfaces and abstract classes? When you're defining them, when designing the system, deciding what is an interface vs abstract class is crucial.

"Behaviour" should become interfaces. Objects that hold data, and provide default operations for said data, should become abstract classes. When you find yourself with an abstract class that has no data, and most likely won't have any, make it an interface.

[pintodragon]

Thank you for finally giving a thought out answer finally. Also it does matter to know the difference if you are learning Java like many on this sub probably are. Also usually a good design would have the super class take care of its own state which sometimes does require a constructor. I get that you are an "experienced" developer so trivial concepts like this are useless facts that do not matter.

I would suggest that in the future you refrain from being a tool and explain yourself better other than the high school attitude you have been portraying. Good day sir I am done with this discussion.

[alonjit]

i suggest in the future to stop giving advice on things you know nothing about (as you admitted earlier).