From virtual extension methods to mixins

["Zdeněk Troníček"]

Can you give any examples of such use? It is not the worst thing if
interface changed its meaning but it would be bad if such change is poorly
justified.

Another example of "poorly justified" proposal are Java properties.
Although p.name may seem better than p.getName() when writing, it is
definitely worse when reading. And if I consider that getters and setters
are generated by IDE, I see the properties as a step in bad direction.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Yuval Shavit napsal(a):
> 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-
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>