From virtual extension methods to mixins

Tom Hawtin tom.hawtin at oracle.com
Wed Jul 11 11:39:40 PDT 2012


On 10/07/2012 13:08, Peter Levart wrote:
> This pattern calls for "protected abstract" methods in interfaces. Maybe in
> Java 9?

And now we effectively have non-abstract methods in interfaces, private 
methods in interfaces.

Cohesion be damned.

> 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. 
The diamond paradox remains. I believe C# allows the multiply derived 
type to implement each method distinctly, which is "interesting".

Tom


More information about the lambda-dev mailing list