Defender Extension Methods -- Resolution and Invoccation

[Howard Lovatt]

My view is that people will find:

interface List {
  List sort() { ... }
  ...
}

Quite natural and will understand the difference between an interface with a
method body and an abstract class. The downside of the present proposal is
that we will see a lot of:

interface List {
  extension List sort() default Trait.sort(List);
  ...
  static class Trait {
    public List sort(List l) { ... }
    ...
  }
}

Which everyone is, rightly or wrongly, going to complain is a lot of boiler
plate.

  -- Howard.

*Brian Goetz* brian.goetz at oracle.com
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=lambda-dev%40openjdk.java.net&su=Defender%20Extension%20Methods%20--%20Resolution%20and%20Invoccation&In-Reply-To=63C3EBA6-0893-44FA-89F8-4160DF472FBB%40miginfocom.com>
 *Wed Aug 4 17:28:26 PDT 2010 wrote:*
------------------------------

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 <http://mail.openjdk.java.net/mailman/listinfo/lambda-dev>*>>* <mailto:brian.goetz at oracle.com <http://mail.openjdk.java.net/mailman/listinfo/lambda-dev>>> 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.*