Virtual extension methods -- a strawman design

[Howard Lovatt]

Comments inline

On Tuesday, May 25, 2010, Nathan Bryant <nathan.bryant at linkshare.com> wrote:
> Yes, and Java up to Java 6 also brushes the problem under the covers...
> by not even attempting to solve it at all.
>
> Fundamentally, this proposal is neither multiple inheritance nor traits.
> It just is what it is: extension methods.
>
> Some of the more important differences:
>
> * If this were multiple inheritance, extension methods could themselves
> reference "super". In this proposal, they can't, because they're just
> ordinary static methods. (MethodHandles from a lookupSpecial would be a
> way to fake that, but I digress.)

Yes, and you could with traits also. With traits you can usually call
any of the supers. With MI and mixins just the immediate super. Since
the extension methods call static methods you can always call these
directly (though not quite as robust in the face of change). On the
plus side calling a static method is very flexible, e.g. a static
method getFirst( List ) could be added to List as getFirst and to
Stack as pop (i.e. very good code reuse and support for method
renaming).

> * The order of implemented interfaces does not affect method resolution,
> as it does for both multiple inheritance and traits.

Not normally with traits, but it does with Scala traits that are some
sort of cross between traits and mixins.

> * As in multiple inheritance, but unlike with traits, "super" is always
> resolved statically.

Normally statically resolved with traits (but not Scala)

> * In some implementations of traits, when a trait gains or loses a
> member, classes that inherit from it must be recompiled without
> exception; it's clear that any implementation with such limitations
> would not meet the requirements for this project. That limitation is not
> the case here; the brittleness limitations being proposed here are more
> limited.

I thought they struck a good compromise that allows for traits to be
modified without too many problems.

> So from the perspective of the principle of least surprise, this
> implementation should be easier to understand for novice programmers
> compared to either multiple inheritance or traits.
>
> The proposal is useful for what it's designed for: widening primitive
> interfaces. It doesn't seem particularly useful for stacking
> modifications.
>
>
>
> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net
> [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Howard Lovatt
> Sent: Sunday, May 23, 2010 8:52 PM
> To: lambda-dev at openjdk.java.net
> Subject: RE: Virtual extension methods -- a strawman design
>
> Alex Blewitt said:
>
>> This is the classic 'diamond problem' that is experienced with
> multiple implementation inheritance.
>> Unfortunately, the proposal document
> (http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf)
>> brushes this under the covers (5.1) with a 'should throw an exception'
> at this point. This is
>> pretty silent, outside of any compiler warnings, and is definitely a
> change of behaviour.
>
> Section 4.2 seems to cover what happens.
>
> "4.2. Resolving ambiguity
> If the class implements multiple extended interfaces, both of which
> provide a default
> implementation for the same method name and signature, the
> implementing class MUST
> provide an implementation.  (This is expected to be a quite unusual
> case.)  The existence
> of the InterfaceName.super.methodName() syntax makes it easy for the
> class to choose
> one of the defaults.  (We might choose to relax this restriction if
> both interfaces provide the same default.)"
>
> This solution is the normal solution for traits, i.e. programmer has
> to resolve the issues.
>
> Alex Blewitt said:
>
>> public class A implements DataStructure {
>>   public boolean filter(FilterSam filter) {...}
>> }
>> // Later, someone makes the change:
>> public interface DataStructure {
>>   extension DataStructure filter(FilterSam filter) default
> Default.filter;
>> }
>
> When A is net recompiled there is a compiler error. If A is not
> recompiled there is a link error. See section:
>
> "5.1. Resolving ambiguity
> In the unlikely case that the VM attempts to load a class that
> implements multiple
> extended interfaces that have a common defender method but with
> different defaults, the
> VM should not attempt to resolve the ambiguity automatically.
> Instead, it should
> generate a bridge method that throws UOE or similar exception.  We
> expect this situation
> to be rare."
>
> I would agree with the assessment that this will be rare and therefore
> catching the error is sufficient.
>
>   -- Howard.
>
>

-- 
  -- Howard.