Defender Extension Methods -- Resolution and Invoccation

[Thomas Jung]

Oh, I've ignored the fact that classes and interfaces are not the same
in this respect as the inner class of an interface is public by
default (i.e. can't be package private). My fault.

Thomas

On 9 August 2010 13:35, Roel Spilker <R.Spilker at topdesk.com> wrote:
> Reinier was refering to inner classes in interfaces.
>
>> -----Oorspronkelijk bericht-----
>> Van: thomas.andreas.jung at googlemail.com
>> [mailto:lambda-dev-bounces at openjdk.java.net] Namens Thomas Jung
>> Verzonden: 09 August 2010 13:24
>> Aan: Reinier Zwitserloot
>> CC: lambda-dev at openjdk.java.net
>> Onderwerp: Re: Defender Extension Methods -- Resolution and
>> Invoccation
>>
>> >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.
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>