Re-specification and re-abstraction

[Yuval Shavit]

Oh shoot, sorry for the double-email. Just noticed a typo in my examples.
Bar should have extended Foo.

On Thu, Dec 22, 2011 at 11:06 AM, Yuval Shavit <yshavit at akiban.com> wrote:

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