Allow: implements AbstractClass
Ulf Zibis
Ulf.Zibis at CoSoCo.de
Fri Sep 14 04:00:43 PDT 2012
Hi and hello first time on this list!
Unfortunately I not have observed the discussion on project Lambda until today.
Reading the fourth draft [1] of "Interface evolution via virtual extension methods" I was concerned
about 3 things:
- ugly syntax
- the need of an external helper class
- is there a technical difference between an interface and an abstract class without any concrete
implementation?
And an alternative approach came to my mind ...
*Allow "implements" on abstract classes* !
If one wants to extend an interface by a method, he should only refactor it to an abstract class and
declare an implementation as a default for that method. E.g.:
class MyClass extends SuperClass implements AbstractClass
The rules from [1] about multiple competing defaults should apply as well, but there would be one
extra opportunity to define the hierarchy on ambiguous methods. Example:
abstract class A { void m() { } }
abstract class B { void m() { } }
class C extends A implements B { }
In this case, A.m() should have priority over B.M(), so there is no need to throw a linkage
exception !!!
The approach also would allow another interesting possibility:
The definition of package private abstract methods to be used as package internal interface methods
which are not visible from outer scope.
[1] http://cr.openjdk.java.net/~briangoetz/lambda/Defender%20Methods%20v4.pdf
Even it that kind of thoughts have been discussed in the past, I would appreciate some conclusive
comments.
Regards,
-Ulf
More information about the lambda-spec-observers
mailing list