From virtual extension methods to mixins

[Brian Goetz]

Java has had multiple inheritance of TYPES from day 1.

What default methods add is multiple inheritance of BEHAVIOR, but not of 
STATE.  The diamond "problem" in C++ most often comes from multiple 
inheritance of state, but we won't have that problem.  (More 
specifically: sometimes you want to inherit two distinct fields, and 
sometimes you want them merged.)

The diamond "problem" in C++ can also come from having multiple 
behaviors for the method, but the inheritance rules (both the existing 
merging rules and the new rules for resolving conflicts in the presence 
of default methods) rule out most anomalous behavior.  (There will 
always be cases where the contracts of two interfaces make it impossible 
for one type to implement them both, but we have that problem today 
without default methods -- for example, it is impossible to implement 
the contracts for both List and Set, but the compiler can't know this.)

You are asserting that there is a "paradox" (or at least a "problem"), 
but you've yet to point to an actual problem.




On 7/12/2012 2:51 PM, Tom Hawtin wrote:
> On 11/07/2012 20:12, Brian Goetz wrote:
>>>> On Monday, July 09, 2012 09:02:41 PM Brian Goetz wrote:
>>>>> Yes, this is what I call the "virtual field pattern." It seems
>>>>> perfectly
>>>>> reasonable to me, because the classes that mix you in have to
>>>>> consent by
>>>>> providing the {get,set}Peeker methods. (Also, by the nature of
>>>>> interface
>>>>> method merging, it addresses the diamond problem as if all base
>>>>> classes
>>>>> were "virtual".)
>>>
>>> "Addresses" in the sense that the choice is taken to use virtual base
>>> type inheritance in the language, without a trace in the source code.
>>
>> That choice was embedded in the nature of interfaces in 1996.
>
> In a slightly different context. 1.00 in January 1996 - practically a
> generation ago - presumably does make a different choice with regards to
> inheriting fields of the same name. I wouldn't wish to brag, but I
> consider myself way in the top fraction of the top percentile of Java
> programmers and I have absolutely no idea what that decision is.
>
>>> The diamond paradox remains.
>>
>> Can you elaborate on exactly how you think the Java 8 semantics lead to
>> a diamond paradox (with emphasis on the "paradox" part)?
>
> I say "paradox" because "problem" is inadequate. I'm sure you could come
> up with half a dozen solutions/ways of addressing the diamond problem
> off the top of your head. But the solutions don't solve the problems
> that the diamond problem brings up.
>
> http://www.google.co.uk/search?q=paradox&tbs=dfn:1
>
>     "1. A statement or proposition that, despite sound (or apparently
>      sound) reasoning from acceptable premises, leads to a conclusion
>      that seems senseless, logically unacceptable, or self-contradictory"
>
> Multiple inheritance seems on the face of it perfectly reasonable, but
> leads to all these rather arbitrary choices.
>
> Tom