Default method survey results

[Zhong Yu]

On Fri, Aug 17, 2012 at 1:36 PM, Yuval Shavit <yshavit at akiban.com> wrote:
> On Fri, Aug 17, 2012 at 1:27 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> On Thu, Aug 16, 2012 at 12:32 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> >> The oddity of "default" implementation is that it puts the programmer
>> >> in a box. He has to provide some sort of implementation that does not
>> >> rely on state. That's an odd place to be in -- especially if no
>> >> suitable implementation can be given without state.
>> >
>> > No, there are plenty of default methods that can be implemented without
>> > access to state.  For example, there are optional methods.  For example,
>> > Iterator.remove() can have a default to throw UOE, so that the 99% of
>> > Iterator implementations that don't want to implement remove() don't
>> > have to implement a version that throws.
>>
>> That means it was a mistake to include remove() in Iterator. And now
>> we use a tool to mask that mistake, ending up with 2 mistakes. There
>> should not be a default impl of Iterator.remove() - a default impl
>> must work in all cases, not just in common cases.
>
>
> Well, throwing UOE from Iterator.remove() *does* work in all cases, in that
> it always conforms to the Iterator contract (which states that you may throw
> UOE from remove()). If you want more interesting behavior, you are free to
> provide it.

What I meant is, the default impl should correct, even if subclass
forgets to override it. While in the Iterator.remove() case, the
default impl is correct, only if subclass deliberately does not
override it. To compiler there's no difference: the method is not
overridden. To human there's a difference.


> That said, it's not clear to me that that's the right behavior. I would
> rather have an abstract UnmodifiableIterator which fills in that method. At
> that point, I think there are a few options:
>
>    - UI is an interface with a default method; its contract is unchanged
> from Iterator's, and it's purely a convenience for implementers
>    - UI is an abstract class, and remove() is final; its contract
> strengthens Iterator's to say that remove() *must* throw UOE
>    - UI is an interface with a default method which also strengthens the
> contract; overriding the default method to provide a non-UOE implementation
> is a bug, but one the compiler can't catch
>    - UI is an interface with a final default method which stengthens the
> contract; maybe in Java 9+ ?