Defender Extension Methods -- Resolution and Invoccation

[Reinier Zwitserloot]

No need to go that far. An implementation provided 'inline' is simply
desugared to a 'default' that points to a nested class, just like the
boilerplate that has been shown in this thread plenty of times already.

What happens if the default method is not accessible/visible from the
caller? i.e. why if the $ExtensionImpls class was private? Can the VM deal
with this as the Defender Extensions spec is currently defined? It's not
currently possible to define anything private in an interface right now, but
allowing "private" on inner classes is a simple change.


Separate from the idea of allowing inline implementations in addition to
pointing at a static method via 'default', how about allowing private inner
types in interfaces _regardless_? Even if inline implementations aren't
allowed, the boilerplate pattern of storing the default implementations in
an inner class is likely to be extremely common, but it REQUIRES that inner
class to be public, and thus visible API. There's absolutely no reason for
an API user to see that thing. It would have to have the following javadoc:

/** Don't look at me. I don't exist. Really. Go away. */

which sounds like something we ought to fix.

This fix becomes a lot more difficult if the 'default' method has to be
visible/accessible from callers.

 --Reinier Zwitserloot



On Thu, Aug 5, 2010 at 1:38 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

> Le 05/08/2010 00:59, Mikael Grev a écrit :
> > Thanks Neal, this reflect my stance as well.
> >
> > Making it hard for the end user is never good. If the purpose of the
> feature is to be able to provide a default implementation for interface
> evolution (which I believe is about time) I think it is better to stand up
> for that and make it as easy as possible to do it.
> >
>
> Hi Mikael,
> I think the syntax of defender method has some technical merits:
> - you can't add code to an interface without breaking all tools that
> take a look
>   to the bytecode.
> - solving the problem of a class implementing two interfaces with two
> extension methods
>   that collide is easier. They should have the same default.
> - you can easily retrofit existing collection API classes/interfaces to
> use extension method.
> - the syntax is close to the VM format. It's not like inner-classes or
> enums
>   where the compiler generate lot of boilerplate code.
>   A simple benefit is that reflection works like a charm.
>
> Rémi
>
> >
> > On Aug 5, 2010, at 0:52 AM, Neal Gafter wrote:
> >
> >
> >> On Wed, Aug 4, 2010 at 3:22 PM, Brian Goetz<brian.goetz at oracle.com>
>  wrote:
> >> Your characterization of "keep interfaces code-free" is pretty close.
>  While
> >> the introduction of default methods unfortunately dirties the
> distinction
> >> between interfaces and classes, we have taken a much smaller step than
> we
> >> could have (say, to mixins or traits or full multiple inheritance) in
> order to
> >> keep as much as possible to the true spirit of interfaces, which we
> still
> >> believe in.  Therefore we believe that choosing a syntactic option that
> >> reflects that this philosophical leaning is in the best interest of the
> >> community.
> >>
> >> It seems you've technically observed the word of "keep interfaces
> code-free" without obeying the spirit of it.  There is little point of
> putting the programmer through the pain of the separation in the current
> specification if the benefits of the separation don't accrue.
> >>
> >
> >
>
>
>