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