From virtual extension methods to mixins

[Zhong Yu]

if you are taking requests, static methods in interface would be nice...

On Tue, Jul 10, 2012 at 5:10 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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-
>
>