Defender Extension Methods -- Resolution and Invoccation

[Paul Benedict]

Correct me if wrong, but did you just point out that default implementations
can change from release to release? I never considered that. Even if Oracle
would never do that :-), it is likely other developers will be less
stringent. Perhaps release X defaults to a quick sort, and release Y
replaces it with a better sort.

I have strong reservations about making interfaces know anything about
implementations.

Would anyone here sign a contract where the other party can freely amend at
will? No Facebook Privacy Policy jokes please :-) But the point being, if I
code to a contract, I don't want someone amending it without me explicitly
implementing it on my end. If the new defender methods add things that are
just ostensibly against my programming model, and change what I think is a
preferred implementation, the idea of a contract is defeated.

Paul

On Wed, Aug 4, 2010 at 8:35 PM, Neal Gafter <neal at gafter.com> wrote:

> Colin has a good point.  Unless the binary compatibility rules prevent you
> from ever changing a defender method's implementation (which would be
> horrible: the whole point of implementations is that they may be changed),
> the compiler must require the programmer to resolve inheritance of multiple
> defender methods, even when the implementation happens to be identical in
> that particular version of the inherited interfaces.
>
> I still don't see any compelling reasons for the separation.  Brian says
> that this prevents the feature from forcing a paradigm shift on
> programmers,
> but the separation appears to increase (rather than reduce) the conceptual
> footprint of the feature and therefore the language.
>
> On Wed, Aug 4, 2010 at 6:16 PM, Collin Fagan <collin.fagan at gmail.com>
> wrote:
>
> > I know I've voiced this before but I'm not a fan of defender methods. I
> > just
> > don't see how this is not already multiple inheritance. Look I'm just
> your
> > average Joe programmer but I don't understand how the statement "a class
> > implementing two interfaces with two extension methods that collide is
> > easier. They should have the same default." can possibly be true. If each
> > interface provides a default how the heck is the programmer supposed to
> > know
> > which one will eclipse the other? Are you saying the default
> implementation
> > needs to point to the same class/method? So when I use an interface from
> > common.lang and one from java.util and there just happens to be a
> collision
> > and they don't share the same default implementation only then am I going
> > to
> > be alerted by the compiler that something is wrong? What happens when the
> > default changes? Does that mean at runtime there will be collsision that
> > was
> > not intended at compile time? Is the default actually part of the method
> > signature? Will I get a method not found exception when there is a
> change?
> > Will every API developer get 1 and only 1 shot at picking a default
> > implementation?
> >
> > I'm sorry I'm really happy with the hard work people are putting into
> this.
> > I'm just totally confused by defender methods.
> >
> > Collin
> >
> >
> > On Wed, Aug 4, 2010 at 7:33 PM, Brian Goetz <brian.goetz at oracle.com>
> > wrote:
> >
> > > On 8/4/2010 7:38 PM, Rémi Forax wrote:
> > >
> > > > I think the syntax of defender method has some technical merits:
> > > > - solving the problem of a class implementing two interfaces with two
> > > > extension methods
> > > >     that collide is easier. They should have the same default.
> > >
> > > This one point alone should close down this discussion!
> > >
> > >
> > >
> > >
> >
> >
>
>