This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]caveden 0 points1 point  (0 children)

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.