Re-specification and re-abstraction

[Yuval Shavit]

As I understand it, the motivation behind defaulted methods is that we'd
like to add new methods to interfaces, but in a way that doesn't break
existing implementations of those methods. From that perspective, there's
no need to have the redeclaration be a no-op; if an existing interface
defined the method, then its implementations would have already defined it.

To my way of thinking, having the redeclaration be a no-op is what breaks
existing behavior. Let's say I have:

    interface Foo {}
    interface Bar { void myMethod(); }

The previous behavior is that, my BarImpl implements Bar would not compile
if I didn't define myMethod() -- that was the behavior Bar's author had
when he wrote the interface (whether or not the author cares is another
question?). With non-re-abstracted default methods, that behavior changes.
The flip side of this is that there isn't existing language behavior for
redeclaration of a defaulted interface method (since those don't exist yet).

Can a defaulted method invoke super.myMethod() (qualified by interface if
needed)? If so, maybe another approach is to have redeclarations
re-abstract by default, but allow them provide a default that calls a
super's default if they're only desired as documentation.

On Thu, Dec 22, 2011 at 9:18 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> [ oops, hit reply too soon ]
>
> >> Looking from the perspective of code evolution: if an interface method
> >> was abstract (non-default) at the start
>
> I think the point you're missing is: when is the start?  At the time
> many of the classes involved were written, the notion of a default
> interface method didn't exist.  At the start, NO methods had defaults.
>
> If we were started over from scratch with a new language, considerations
> of "existing code does ... which means ..." would be irrelevant.  But
> we're not in that world.
>
>
>