From virtual extension methods to mixins

[Tom Hawtin]

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