Review request:
http://cr.openjdk.java.net/~anazarov/default-methods/webrev.00/


Copy of the discussion form e-mail:
-------------------------------------------------------------------------
On 13 Sep 2013, Brian Goetz wrote:

In the example of Iterator.remove, you should show the code in Iterator that declares remove() as a default method.

I don't think you need to talk in terms of resolution; I think users think more in terms of inheritance.

Phrasing like "Let's see another sample demonstrating that code could not be compiled if the method in superclass is abstract:" can be simplified to:

"If the method in a superclass is abstract, a concrete subclass must provide an implementation"

"This is still true with support for Evolving Interfaces" -- kind of makes the change sound bigger than it is. The idea is that default methods are *just plain old abstract method*, except they also have a body that can be inherited. The only remaining rules are those having to do with conflicts between inheritance candidates, and even there, there's only two simple rules:

1. Class wins. If the superclass has a concrete or abstract declaration of this method, it is preferred over all defaults.

2. Subtype wins. If an interface extends another interface, and both provide a default, the more specific interface wins.

If, under these rules, there's one winner, we're done, otherwise the user has to implement the method (as if it were abstract.)

I think the "mixin" treatment is more complicated than it needs to be. Instead, look at the forEach method in Iterable. You could write a mixin-style interface like:

    interface Eachable<T> extends Iterable<T> {
        void forEach(Consumer<? super T> c) {
            for (T t : this)
                c.accept(t);
    }

and just mix in Eachable to get the 'forEach' method. (Of course, Iterable already has forEach, but you could do something like SkippableIterator<T> that provides a skip() method.)

I think that's an example that gets to the punchline faster.
===


On 16 Sep 2013, Alexandre Iline wrote:

Brian, guys,

This demo spec went through a few iterations so not that clear - sorry about that. That said, it is still a spec. Similar to other specs, whatever text is there will remain there. The actual demo code is going to be in java, which we will provide for review as soon as we are sure you are ok with conceptually with what is going to be in the code. Some of the text may actually re-appear in the demo in comments, so the suggestions on wording are welcomed.

With that, I would like to ask for a few clarifications.

Iterator.remove already exists. The only way to show its code is in comments. An alternative is to have some other interface which would have a methods throwing an unsupported exception of a kind. Accompanied with a couple more classes this would be clearer. We could refer in comments to the Iterator.remove, saying that the example mimics what's done there.

We are going to developed a smaller mixin, along the lines with what said, among other places, in wikipedia: "a mixin is a class which contains a combination of methods from other classes". The code will consists in a couple of interfaces, each with default methods, and a class implementing both. There could be some shared state methods in the interfaces if we would be capable of coming up with a god example.

We will have a separate code to show the inheritance rules. We will make sure that the inheritance rules are clearly seen in the code and well marked in comments.

Let me know if you not ok with this, otherwise we are proceeding with the plan.
===


On 17 Sep 2013, Brian Goetz wrote:

> Iterator.remove already exists. The only way to show its code is in
> comments. An alternative is to have some other interface which would
> have a methods throwing an unsupported exception of a kind. Accompanied
> with a couple more classes this would be clearer. We could refer in
> comments to the Iterator.remove, saying that the example mimics what's
> done there.

What I meant was: the Iterator example is a good example of how to *use* default methods, so having the users see how easy it was to evolve Iterator will make them realize it is easy to evolve their classes too.

> We are going to developed a smaller mixin, along the lines with what
> said, among other places, in wikipedia: "a mixin is a class which
> contains a combination of methods from other classes". The code will
> consists in a couple of interfaces, each with default methods, and a
> class implementing both. There could be some shared state methods in the
> interfaces if we would be capable of coming up with a god example.

A good example might be

  interface Debuggable {
    default String toDebugString() {
        // Use reflection to find all the accessible fields, and format them into a string
    }
  }

and then classes that implement Debuggable could provide their own toDebugString() impl?

> We will have a separate code to show the inheritance rules. We will make
> sure that the inheritance rules are clearly seen in the code and well
> marked in comments.

Make sure to stress the Three Simple Rules:

1. Classes win over interfaces
2. Subtypes win over supertypes
3. No rule 3! If there's not already a unique impl to inherit, you have to provide it.
===


On 29 December 2013, Robert Field wrote:

Egads!

The default method demos are appalling. Because, I guess, they didn't
get that default methods are on interfaces and interfaces can define
abstract methods, the demos are all reflection based, thus more
reflection demos than default method demos. Rather than show real world
usage, they have stateless classes representing animals. They use
concepts and words we have pointed avoided -- specifically, mixin. The
majority of the text is grammatically incorrect.

I see nothing salvageable.
===

On 14 Jan 2014, Alexandre Iline wrote:

Robert, guys.

 * Reflection vs. abstract methods.
We had an argument internally on whether the state could be returned by
abstract methods or by reflection. However hard I was fighting against
using reflection, the winning decision was to use it because this is
what Brian Goetz suggested.

* Animals vs real world example.
The true usage for the default methods is to extend libraries while not
breaking existing code - we all know that. The trouble is, it is hard to
demonstrate this in a demo. It is best and enough demonstrated by the
JDK 8 itself. The other use is the "multiple inheritance". We just did
not find a better example than the Pegasus. We did not particularly like
it either, just nothing better came up.

* Mixin
Well ... ppl are talking about mixins in JDK 8 - regular java
developers. I have seen it brought up. This is a concept which, been
available in some other languages, is very familiar to many. The moment
JDK 8 will start to be used, many will start using the concept whether
or not to call it a "mixin". If that is prohibited somehow, we need drop
it, of course.

* The grammatical incorrectness we were supposed to fix - we dropped the
ball somewhere. For all the demos we have asked doc writers to review
javadoc comments. This one was missed, apparently - I have found it
already - the comments will be fixed even though the demo may be thrown
away.


All in all, please throw any idea of a useful demo our way. We will have
somebody to implement it.

Thank you.
-------------------------------------------------------------------------