Vritual extension methods

[Rémi Forax]

On 07/08/2012 10:54 AM, Deepak S Patwardhan wrote:
> Brian,
>
> I have gone through the State of Lambda, 4th edition, but don't think it
> answers my questions. Let me rephrase them.
>
> C1: public Complex subtract(Complex b) default { return
> this.add(b.negate()); }
> C2: public Complex divide(Complex b) default Complexes.divide;
>
> 1) Why have we broken the rule - interfaces don't have code ? Is the
> construct  C1 strictly more powerful than C2 ?
> 2) Why are we using . (dot) in C2 instead of :: (colon colon) - the choice
> for method references in lambda expressions ?
>
> Regards,
> Deepak S Patwardhan.

Hi Deepak,
the syntax of C2 was an attempt to solve the problem of adding new methods
that support lambdas in Collection API without breaking the golden rule 
"no code in interface"*
This syntax predates the introduction of the double colon syntax for 
method reference.

This syntax has several drawbacks that we discover when trying to 
specify its semantics and
to implement it in the compiler.
Here is an example,

interface A {
   void m() default Garbages.foo;
}
interface B extends A {
}
class Garbages {
   void foo(A a) { ... }
   void foo(B b) { ... }
}

The question is what new B() { }.m() should call.
The other problems was how to deal with generics signature, the fact 
that you force users to write
side class (the class Garbages), and maybe some other problems I've 
forgotten.

So we decide to move to something more object oriented, and put code in 
interface.

Rémi

*BTW, since Java 1.1, you have code in interfaces because initializing a 
static final field
may create a static block.

>
> -----Original Message-----
> From: Brian Goetz [mailto:brian.goetz at oracle.com]
> Sent: 04 July 2012 21:18
> To: Deepak S Patwardhan
> Cc: lambda-dev at openjdk.java.net
> Subject: Re: Vritual extension methods
>
> See the relevant section of State of the Lambda, 4th edition, which
> supersedes this.
>
> On 7/4/2012 10:37 AM, Deepak S Patwardhan wrote:
>> Hello,
>>
>>
>>
>> The Defender methods v4 document (Brian Goetz, June 2011) has two
>> interesting foot notes (page 2)
>>
>>
>>
>> 5. It is a deliberate choice to not simply allow the programmer to
>> include the code of the default inline
>>
>> within the interface. Among other reasons, it would violate the
>> long-held rule that "interfaces don't have
>>
>> code".
>>
>>
>>
>> 6. The syntax of specifying the default implementation should match
>> that of specifying method references, if
>>
>> method references are to be added to the language.
>>
>>
>>
>> Consider the following code (which compiles successfully with build
>> 39)
>>
>>
>>
>> /* Complex.java */
>>
>> /** Represents Complex numbers */
>>
>> public interface Complex {
>>
>>
>>
>>       public Complex add(Complex b);
>>
>>
>>
>>       public Complex negate();
>>
>>
>>
>>       public Complex subtract(Complex b) default {
>>
>>           return this.add(b.negate());
>>
>>       }
>>
>>
>>
>>       public Complex multiply(Complex b);
>>
>>
>>
>>       public Complex invert();
>>
>>
>>
>>       public Complex divide(Complex b) default Complexes.divide;
>>
>> }
>>
>>
>>
>> /* Complexes.java */
>>
>> public class Complexes {
>>
>>
>>
>>       public static Complex divide(Complex a, Complex b) {
>>
>>           return a.multiply(b.invert());
>>
>>       }
>>
>>
>>
>> }
>>
>>
>>
>> First Question:
>>
>> As I am able to write a method body for subtract, the rule mentioned
>> in footnote 5, interfaces don't have code, seems to have been ignored.
>> Has this been finalized or will this be disallowed in a future build ?
>>
>>
>>
>> Second Question:
>>
>> Consider the default clause of the divide method. The syntax used for
>> the method reference is ClassName.methodName. In section 8 of State of
>> Lambda v4 (Brian Goetz, December 2011), method references have syntax
>> ClassName::methodName. It also states that this syntax is provisional.
>> Example, map method of Iterable takes method references in this syntax.
>>
>>
>>
>> List<String> names = .
>>
>> nameLengths = names.map(String::length);
>>
>>
>>
>> Will the syntax for specifying the default method change to (only) use
>> ClassName::methodName, in a future build ? Otherwise, footnote 6 also
>> seems to be ignored for now.
>>
>>
>>
>> Regards,
>>
>> Deepak S Patwardhan.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>