Default method survey results

[Talden]

There's a developer-facing reason the class is marked as abstract.  It
seems to me a VM implementation detail that the interface would be
marked as 'default' since it's not interfaces that collide but the
method signatures.

A class with abstract methods is prevented from being instantiated -
pretty fundamental to the usage of the _class_ independent of the
method that is actually abstract.  Additionally you may mark a class
abstract just to prevent instantiation of an internal design detail
even though it has not abstract methods.

I don't see that marking an interface with default tells the developer
anything they don't have to know about individual methods.

In our code-base I expect to move methods from static-helper classes
to interfaces they serve - in some cases a possibly non-trivial number
of them.  However understanding the responsibilities of implementing
that interface is tougher if the default methods aren't clearly
differentiated from the abstracts.

Yes the IDE is going to help you and yes the rendered javadoc can
infer it and indicate defaults, but sometimes people are looking at
the source and a keyword is typically syntax-highlighted distinctly
enough to help quite a bit in a typical interface.

  interface Whatsit {
    Whatsit foo(Whatsit other);
    Whatsit bar();
    Whatsit baz() { foo(bar()); }
  }

vs

  interface Whatsit {
    Whatsit foo(Whatsit other);
    Whatsit bar();
    default Whatsit baz() { foo(bar()); }
  }

Mix in some javadoc and you could miss that method body...

--
Aaron Scott-Boddendijk


On Thu, Aug 16, 2012 at 10:48 PM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 16/08/12 11:03, Stephen Colebourne wrote:
>> So for me, there are two valid designs:
>>
>> // full option - exact parallel to abstract classes
>> // "only default interfaces can have default methods"
>> default interface {
>>    <method_no_body>
>>    default <method_with_body>
>> }
>>
>> // minimal option - no cruft
>> // "as simple as possible"
>> interface {
>>    <method_no_body>
>>    <method_with_body>
>> }
>>
>> The current lambda option feels like a messy halfway house:
>> interface {
>>    <method_no_body>
>>    default <method_with_body>
>> }
> Point taken, thanks for clarifying your point - the fact that this whole
> thread has been focussed on the 'why don't you leave the D-word out'
> rather than on the 'why don't you add the D-word on the interface too'
> probably contributed biasing the discussion too.
>
> I think a keyword on the interface would not be that alien, as both the
> compiler and the VM are synthesizing a flag to mark 'interfaces with
> default methods'. Your proposal is about making this logic explicit
> (since everything else is explicit too).
>
> Let's keep this on the back of our mind for a while and see how it pan out.
>
> Maurizio
>
>
>
>