Re-specification and re-abstraction

[David Holmes]

On 23/12/2011 2:07 AM, Yuval Shavit wrote:
> 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
> <mailto: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.

The case of adding a new method with a default is not at issue. It is 
the case of adding a default to an existing method. It doesn't impact 
classes that already implement the interfaces.

>     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 [extends Foo ] { 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.

I still don't understand your example even with Bar extending Foo. Where 
is the default method being added? What "previous behaviour" are you 
referring to?

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

As Brian has indicated you can access the immediate super default if it 
exists. That would allow the subinterface author to update their 
interfaces to indicate that the new default in the super interface is 
indeed suitable for use with the subinterface.

David Holmes
------------

>     On Thu, Dec 22, 2011 at 9:18 AM, Brian Goetz <brian.goetz at oracle.com
>     <mailto: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.
>
>
>
>