Virtual extension methods -- a strawman design

[Neal Gafter]

On Tue, May 25, 2010 at 11:35 AM, Peter Levart <peter.levart at gmail.com>wrote:

> On Monday 24 May 2010 07:01:58 am Neal Gafter wrote:
> > Both default behaviors can be improved by recognizing that these
> > different methods don't have to resolve to the same implementation:
> >
> > If both interface A and interface B declare defender methods with the
> > same signature, there is no ambiguity in a class C that extends A and
> > B.  Invoking the method through C is a compile-time error (ambiguous),
> > invoking through A gets A's behavior, and invoking through B gets B's
> > behavior.  There is no need to guess how rare these cases might be.
> >
>
> How could this be achieved without modifying the specification of the JVM?


Adding extension methods as contemplated requires changing the JVM
specification.


> How could C provide distinct implementations of a method with the same name
> and parameter types
> that would be selected in response to invoking them via interface A or B?


Doing that would require additional language support.  If it is deemed worth
doing there is an obvious syntax to use.


> Is it possible for
> code emited by javac in the single method body to find out via which
> invokeinterface method it
> was actually invoked and dispatch accordingly?
>

I don't propose such a thing.