Virtual extension methods -- a strawman design

[Stephen Colebourne]

On 15 May 2010 00:16, Brian Goetz <brian.goetz at oracle.com> wrote:
> Comments to the effect of "I like XYZ other scheme better" are not.  (Where
> XYZ could be use-site extension methods, traits, mixins, etc.  Those have
> already been considered and rejected as viable approaches for Project
> Lambda.)

Sigh.

I perfectly well understand that Oracle has met, discussed and decided
to reject other options. The problem is that you've not done it
/publicly/. As such, those of us outside Oracle are left with guessing
at what thought processes you went through and reasoning you had. This
makes it nigh on impossible to provide the meaningful feedback you'd
like, or for you to win the trust of the broader community.

Anyway...

As it happens, I like the direction of the document. It enables class
specific overrides of extension methods (which I consider essential)
and manages the whole approach in an easy manner. It also solves my
concern of a method not being in the immediate hierarchy of the object
(and thus easily findable in the standard way).

The approach does prevent users from adding there own methods to
classes/interfaces, but I've always found that a little dubious. For
that requirement, I'd prefer a different language change that made
clear at the call-site that the methods are added by someone other
than the API writer. I don't see a pressing need for that however, so
the proposal covers the main use case.

Personally, I would prefer to be able to write the implementation
inline in the interface. Such an approach makes more sense that
forcing the creation of public classes with random static methods.

If the target is JDK7 then I agree with the idea of this being a
compiler only approach. However, if this targets JDK8, then I would
argue that a JVM based solution is probably more complete overall. ie.
I believe that there is a timescale compromise here.

Finally, I'd note that this language change affects design in JSR-310.
Currently we choose an abstract class instead of an interface as its
the only way to permit future evolution. If this change was going in,
it might affect what the API.

Stephen