Defender Extension Methods -- Resolution and Invoccation

[Thomas Jung]

>but it REQUIRES that inner  class to be public, and thus visible API.

package x;
public class X {
    class A{};
}

That's not true. X.A can only be accessed from the package x. (So you
have to generate javadoc with -package to expose the class A.)

Although a private class would be nicer and inlined methods even nicer.

Thomas

On 9 August 2010 13:08, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> 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.
>> >>
>> >
>> >
>>
>>
>>
>
>