From virtual extension methods to mixins
Peter Levart
peter.levart at marand.si
Tue Jul 10 05:08:17 PDT 2012
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