Virtual extension methods -- a strawman design
neal at gafter.com
Tue May 25 14:29:11 PDT 2010
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
> 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.
More information about the lambda-dev