Virtual extension methods -- a strawman design

[Rémi Forax]

Le 15/05/2010 16:35, Stephen Colebourne a écrit :
> 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.
>    

A compiler only approach will not work because
introducing a new method in an interface breaks the *binary*
compatibility.

like Neal, I am in favor of a VM only approach.

> 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
>    

Rémi