Defender Extension Methods -- Resolution and Invoccation

[Brian Goetz]

Your are being tripped up by the belief that most Java users are like you! 
(And we all know there's only one of Neal.)

The vast majority of the 12M+ Java developers will probably never use this 
feature.  But doing it this way saves us from imposing what will look like a 
significant paradigm shift on them, which would certainly rock their world for 
little benefit.

While I will not repeat the mistake of claiming any language feature will be 
used "exclusively by library writers", I am willing to put library maintainers 
to some additional small inconvenience (and it is small) if it benefits the 
community at large (and the benefit is large.)

> 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.

The benefits of the separation do accrue, most definitely, to those users.


On 8/4/2010 6:59 PM, Mikael Grev wrote:
> 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.
>
>
> 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
>> <mailto: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.
>