Defender methods and compatibility

[Rémi Forax]

On 11/25/2010 02:22 AM, Neal Gafter wrote:
>>> Anyway, the good news is that mod-extn _is_ SC. That's true whether a
>>> default is specified in the interface via a method body or a method name.
>>>
>> Should have said: mod-extn _may be_ SC. When an implementation class
>> doesn't override the extension, it's possible for previously-identical
>> extension methods to diverge (i.e. one changes its default) and break SC.
>>
> Understood.  That is the particular part of the specification that I take
> issue with.  mod-extn (changing the code of a default method) should (in my
> opinion) always be source compatible, as the code of a method is a prime
> example of an implementation detail.
>

There is perhaps a way to satisfy both parties :)

I'm not in favor to use the default methods to disambiguate when
there are several extension methods. As Neal said, the default method
is part of the implementation.

I propose to use the declaring type instead of the default method
to disambiguate.
Let's take several examples:

   interface Foo {
     extension void m() default Foos.m;
   }
   interface Bar {
     extension void m() default Bars.m;
   }
   class A implements Foo, Bar { }

   A::m can be Foo::m or Bar::m, because
   there is no most specific type between Foo and Bar,
   a call to A::m should throw a linkage error.

   interface Foo {
     extension void m() default Foos.m;
   }
   interface Bar extends Foo {
     extension void m() default Bars.m;
   }
   class A implements Foo, Bar { }

   A::m can be Foo::m or Bar::m, because
   Bar is a sutype of Foo, a call to A::m will
   call the default method of Bar::m, Bars.m.

   interface Foo {
     extension void m() default Foos.m;
   }
   interface Bar extends Foo {}
   interface Baz extends Foo { }
   class A implements Bar, Baz { }

   A::m can be Foo::m or Foo:m, so a call to
   A::m will call Foos.m.

   Rémi