Default method survey results

[Stephen Colebourne]

On 16 August 2012 09:43, maurizio cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>> Now consider this code:
>>
>> interface Foo {
>>    public String process(int a, String b) default Utils#processFoo
>> }
>> class Bar {
>>    public String process(int a, String b) default Utils#processBar
>> }
>>
>> The Foo version is being talked about for JDK8/9, yet the Bar version
>> isn't. Why not? What is the difference here that justifies support for
>> this feature in interfaces and not classes? None I'd suggest. But
>> here, a keyword of some sort does make some sense - its a new feature
>> not seen anywhere today. Methods that can be inherited are not a new
>> feature, just one appearing in a new location (interfaces), thats why
>> they don't need extra syntax.
>
> I would say that the keyword 'default' in the class looks weird at best -
> why 'default' ? In an interface, default means that it's some kind of
> 'last-chance' attempt at providing an implementation for a given method -
> hence the 'default'. There are already things in the model that make
> inheritance between classes and interface asymmetric (towards classes) - for
> example:
>
> interface A {
>    void m() default { ... }
> }
>
> class B {
>    abstract void m();
> }
>
> class C extends B implements A { } //m is abstract in C
>
> Which kinda makes the point about 'defaultness' even stronger: the default
> method is used _only if_ no other method exists in the superclass hierarchy.
> This concept simply does not scale to classes, so I don't buy the
> 'similarity' argument here. But, more importantly, for 99% of developers an
> interface is - well, just an interface, an entity with a set of abstract
> methods, no implementations. The fact that implementations will start to
> appear in interface is potentially confusing to those developers, and we
> think that the use of a keyword (which, btw, reflect the semantics pretty
> well, as described above), will help developers to understand more quickly
> things like i.e. which methods they need to implement when implementing an
> interface. Also, let's not play down the Javadoc factor: once you name a
> method 'default method' you can use the D-word in javadoc to tag the method,
> and you have a nice 1-1 mapping between source code and documentation.

Methods appearing in interfaces really isn't confusing. Its new, yes,
but no developer is going to be confused about the intent of the code.
Its obviously a method declaration, and method declarations are
inherited. ie. the developer can guess what the code will do and it
passes the 5-minute test **.

The complications here are in the detailed rules of inheritance in
special cases like the one you outline. Such special cases are no
different to the case of a concrete method in overridden by an
abstract method in a subclass. This kind of edge case is one

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

BTW, I don't think anyone is arguing about typing 7 letters on a
keyboard. Its all about expressing the code in the most effective way
for future readers.

Nor is it a syntactic rat-hole - the real discussion is about the
mental model that this feature is selling to developers, and how that
is exposed in documentation and syntax.

Stephen

** the 5-minute test: a feature that can be learnt in 5-minutes by a
more senior devloper leaning over the shoulder of a junior developer.