> *appropriate when the new method can be defined in terms of other
existing methods in the interface*
This is what it means when a method employs the "template" design pattern.
Correction to my (earlier) example:
@FunctionalInterace
interface Sorter {
default Object[] sort(Object... array) {
return *sort*(Arrays.asList(array)).toArray();
}
<T extends Iterable<?>> T *sort*(T collection);
}
-j
On Fri, May 8, 2020 at 1:03 PM Owen Nichols <onich...@pivotal.io> wrote:
> Default interface methods are especially appropriate when the new method
> can be defined in terms of other existing methods in the interface. For
> examples, when Collections added isEmpty(), it is basically just a
> shorthand for length()==0 [but certain subclasses might still be able to
> provide a more efficient implementation, for example a linked list might
> require traversing the entire list to get the length, while isEmpty could
> simply check the head].
>
> For public APIs, adding a new default interface method is safe (will not
> break source or binary compatibility), but for internal APIs, we don’t
> promise backward compatibility anyway.
>
> The pattern of adding a new default interface method with an empty
> implementation does concern me. Perhaps a new interface that extends the
> original would be a more compile-time-verifiable way to express that new
> optional methods have been added that only some but not all implementations
> might implement?
>
>
> > On May 8, 2020, at 11:31 AM, John Blum <jb...@pivotal.io> wrote:
> >
> > Another way to think about this is:
> >
> > 1. First, default methods are not inherently bad. They are useful in many
> > situations and can be "overridden" on implementing classes, if necessary.
> > 2. A default method should be provided when the operation is not strictly
> > required or if the implementation (procedure/algorithm) is rather simple
> > (e.g. following the template pattern), for example...
> >
> > @FunctionalInterace {
> > interface Sorter {
> >
> > default Object[] sort(Object... array) {
> > return convert(Arrays.asList(array)).toArray();
> > }
> >
> > <T extends Iterable<?>> T convert(T collection);
> >
> > }
> >
> > 3. If the interface footprint is small (as it should be) then it is
> > possible to use in *Lambda* expressions (and *Method References*), as
> > proper @FunctionalInterface as shown above, which is very useful when
> > composing *Streams*, etc.
> >
> > Food for thought.
> >
> > -j
> >
> >
> > On Fri, May 8, 2020 at 10:17 AM Jacob Barrett <jbarr...@pivotal.io>
> wrote:
> >
> >> As a general rule default implementations on an interface should only
> used
> >> when absolutely necessary because all the implementations are out of
> your
> >> control. For example, the collection interfaces in the JDK all gained
> new
> >> APIs but Java doesn’t implement every instance of them so a default is
> >> necessary for forward progress. However, if you own all instances you
> >> should not need to use default. So in this particular PR the use of
> default
> >> in the InternalCache in my opinion is wrong. We should control all
> internal
> >> interfaces and therefor can update them all with the correct
> >> implementation.
> >>
> >> -Jake
> >>
> >>> On May 8, 2020, at 9:49 AM, Kirk Lund <kl...@apache.org> wrote:
> >>>
> >>> I believe some of the Geode community has already decided that we
> >> shouldn't
> >>> overuse default methods in interfaces. Dan and others were the ones who
> >>> decided this and thus I can't really explain to folks in PRs why it's
> bad
> >>> to overuse default methods. Could some of the folks with strong
> >>> understanding of why we should avoid making every method default empty
> >>> please speak up here and/or in
> https://github.com/apache/geode/pull/5014
> >> ?
> >>>
> >>> My understanding is that default implementations should only be
> provided
> >> in
> >>> interfaces when it's important to do so for facilitating some sort of
> >>> deprecation and replacing a deprecated method.
> >>>
> >>> Thanks,
> >>> Kirk
> >>
> >>
> >
> > --
> > -John
> > Spring Data Team
>
>
--
-John
Spring Data Team
