Public defender methods and static inner classes in interfaces?

[Jim Mayer]

Hi Dave,

The "defender method" idea seems useful to support extension of existing
interfaces, but I'm worried that the ability to put algorithms into
interfaces will blur the distinction between interfaces and classes.  One of
the problems with C++ is that there are so many ways of doing the same thing
that the conventions around the use of a feature become more complicated
than the feature itself.

Currently interfaces have a well defined purpose: they specify a contract
without an implementation.  That's a simple concept to get across and the
language enforces it.  Once we allow algorithms to be implemented in
interfaces the picture becomes less clear, especially for inexperienced
developers.

On the other hand, Java interfaces can already contain constants and it's
hard to argue why, since we're adding lamba like expressions to Java, we
shouldn't just treat the default methods as constant values.  In fact, I
think the cleanest proposal is to let interface method definitions have
bodies... that's the most familiar syntax of all.  I'm just worried about
unintended consequences... interfaces were introduced, I assume, because of
the widespread concern about multiple inheritance.  Defender methods raise
the same issues as multiple inheritance, and the rules for resolving
ambiguity are (necessarily) non-local in effect.  Adding a new method with a
"defender" seems like an innocent change to an interface, but the non-local
nature of the conflict resolution algorithms means that it will be easy to
break existing code or, perhaps worse, produce code that yields unexpected
results.

Anyway, that's why I would prefer something like the proposal in (
http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf).  It's ugly, and that
seems appropriate here. :-)

-- Jim

On Wed, Sep 8, 2010 at 1:27 PM, David Walend <david at walend.net> wrote:

> On Sep 8, 2010, at 8:59 AM, Jim Mayer wrote:
>
>  One problem with the suggestion below (that 'private' be allowed on
>> classes inside interfaces) is that it won't play nicely with unit testing
>> frameworks such as JUnit.  JUnit conventions rely fairly heavily on
>> 'package' protection, and a 'private' class inside an interface would be
>> difficult to test.
>>
>> This may, or may not, matter in practice, but I hate to see us do anything
>> that makes unit testing harder.
>>
>> My own preference, at this point, would be to keep implementation out of
>> interfaces as much as possible, provide implementations in a separate file,
>> and hope that the defender method feature isn't abused too much.
>>
> <snip>
>
> Jim, this is what I'm curious about. What do you see as abuse (vs. wise
> use)?
>
> We can take this off list if no one else is interested. It's sure to stray
> into syntax.
>
> Thanks,
>
> Dave
>
>
>