Defender Extension Methods -- Resolution and Invoccation

Mikael Grev grev at miginfocom.com
Wed Aug 4 15:59:55 PDT 2010


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



More information about the lambda-dev mailing list