From virtual extension methods to mixins

[Yuval Shavit]

Judging from the buzz around non-Java JVM languages, I think your hope is
probably naive. Imho, people *will* use this feature for more than just API
evolution, and trying to ignore or discourage that will just mean you won't
have a say in how it's done. I don't think it would be the worst thing in
the world if interfaces' meanings evolved slightly in the 20 years since
they were invented.

On Sun, Jul 15, 2012 at 1:51 PM, "Zdeněk Troníček" <tronicek at fit.cvut.cz>wrote:

> 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-
> >>
> >>
> >
> >
> >
>
>
>