From virtual extension methods to mixins
Brian Goetz
brian.goetz at oracle.com
Tue Jul 10 15:10:10 PDT 2012
Maybe :)
On Jul 10, 2012, at 8:08 AM, Peter Levart wrote:
> This pattern calls for "protected abstract" methods in interfaces. Maybe in
> Java 9?
>
> Peter
>
> 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".)
>> On Jul 9, 2012, at 8:00 PM, Yuval Shavit wrote:
>>> Stateful mixins like this do indeed seem like a sketchy idea to me -- but
>>> is there any official stance on other mixin-like ideas? For instance, it
>>> seems to me you could use defender methods to implement delegation. For
>>> instance:
>>>
>>> interface Peeker<T> {
>>>
>>> T peek();
>>> T take();
>>> // maybe some other methods...
>>>
>>> }
>>>
>>> interface PeekerView<T> extends Peeker<T> {
>>>
>>> Peeker<T> getPeeker();
>>>
>>> T peek() default { return getPeeker().peek(); }
>>> T take() default { return getPeeker().take(); }
>>>
>>> }
>>>
>>> Now you can become a Peeker just by having one. All of a sudden, it's very
>>> easy to be a Peeker, a List and any number of other things.
>>>
>>> public class BagOTricks<T> implements PeekerView<T>, ListView<T>,
>>> SupplierView<T> {>
>>> private List<T> underlying = ...
>>> private Peeker<T> peeker = new ListPeeker<T>(underlying);
>>> private Supplier<Optional<T>> supplier = new
>>> ListSupplier<T>(underlying);
>>>
>>> @Override
>>> public Peeker<T> getPeeker() {
>>>
>>> return peeker;
>>>
>>> }
>>>
>>> @Override
>>> public List<T> getList() {
>>>
>>> return underlying;
>>>
>>> }
>>>
>>> @Override
>>> public Supplier<Optional<T>> getOptionalSupplier() {
>>>
>>> return supplier;
>>>
>>> }
>>>
>>> }
>>>
>>> On Mon, Jul 9, 2012 at 4:38 PM, François Sarradin <fsarradin at gmail.com>
>>> wrote: Brian,
>>>
>>> Thank you to share your advice. I think that my article provides a bad use
>>> of Java too. I don't really encourage this. I am just saying it is
>>> possible
>>> and let the reader decides if it is good or bad.
>>>
>>> It is a good thing to share best practices, in a view to build "well
>>> craft"
>>> software. I have done this with small demonstrations of Java's lambda at
>>> Devoxx France this year. Moreover, I think you know that you can also find
>>> more and more articles about such best practices in Java 8 (even in French
>>> ;) ). But I really think that we also have to share worst practices. This
>>> is motivated by the wish to identify them and prevent them. That is why I
>>> wanted to share such an article, even if it is unpleasant.
>>>
>>> François-
>>>
>>> Le 9 juil. 2012 13:50, "Brian Goetz" <brian.goetz at oracle.com> a écrit :
>>>> Please don't encourage techniques like this. There are a zillion
>>>> "clever"
>>>> things you can do in Java, but shouldn't. We knew it wouldn't be long
>>>> before someone suggested this, and we can't stop you. But please, use
>>>> your
>>>> power for good, and not for evil. Teach people to do it right, not to
>>>> abuse it.
>>>>
>>>> On Jul 9, 2012, at 1:12 AM, François Sarradin wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to share a blog post. It explains how to get multiple
>>>>> inheritance of the state from the virtual extension methods.
>>>>>
>>>>> "Java 8: Now You Have Mixins!" =>
>>>>> http://kerflyn.wordpress.com/2012/07/09/java-8-now-you-have-mixins/
>>>>>
>>>>> François-
More information about the lambda-dev
mailing list