Defender Extension Methods -- Resolution and Invoccation

[Mikael Grev]

Hello Rémi,

Can't this all easily be solved by having the compiler or VM auto generate a class with the implementation?

Also note that of course that the current syntax should also be allowed.

Best of both worlds?

Cheers,
Mikael


On Aug 5, 2010, at 1:38 AM, Rémi Forax 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.
>>> 
>> 
>>