From virtual extension methods to mixins

["Zdeněk Troníček"]

No, they wouldn't. Nor the protected methods. Interfaces are a means to
define the component API and although they enable multiple inheritance in
some sense, we should not view them this way and should not let them
evolve to abstract classes.
As Brian says elsewhere, the extension methods allow interfaces to evolve.
So all this discussion seems to be not properly motivated because the
examples does not seem to have anything common with API evolution.
Nevertheless, if everybody involved view the discussion as "discussion on
theoretical aspects and corner cases of extension methods", it is valuable
and funny.
I, personally, hope that average application programmer will mostly ignore
the extension methods and if use them, then only for interface evolution.

Zdenek
-- 
Zdenek Tronicek
FIT CTU in Prague


Zhong Yu napsal(a):
> 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-
>>
>>
>
>
>