Method Bodies in Interfaces -- Why Not?

[Reinier Zwitserloot]

Unless I'm gravely mistaken about the idea behind Project Coin, your  
idea isn't even remotely close to what's considered 'small' enough for  
project coin.

I proposed relaxing interfaces just a little and allow adding static  
methods (that don't even inherit to avoid the pitfalls of that idea).  
That one is walking the line already.

Not trying to cast aspersions against the idea (on the contrary, I've  
long considered such a system to be preferable, and many languages  
including Scala allow it), just saying that project coin isn't the  
right venue for it.

  --Reinier Zwitserloot



On Mar 11, 2009, at 00:38, David Walend wrote:

> A lot of us spend energy dealing with the fact that we can not add
> methods to interfaces. We can't add methods to interfaces because
> everything that implements those interfaces would break. We could get
> around that by letting interface-defined methods have method bodies.
> The resulting problem is that the compiler would not be able to choose
> between or order method bodies with the same signature. (As I
> understand it, that's why interfaces can't have method bodies.)
>
> It's modestly rare for classes to inherit two interfaces that define
> methods with the same signature in the wild. What happens if the JLS
> were to relax the constraint?
>
> I imagine a few options:
>
> With multiple inheritance, if different implemented interfaces define
> bodies for methods with the same signature then:
>
> 1) Give the developer a compile error or
> 2) Inherit neither method body and force the developer to implement
> something himself or
> 3) Inherit neither method body, force the developer to implement
> something himself, and give him some way to access to all the  
> inherited
> implementations.
>
> That would let us out of some of our more painful contortions. What
> are the holes in that idea?
>
> Thanks,
>
> Dave
> david at walend.net
>
>