Default method survey results

[Zhong Yu]

On Fri, Aug 17, 2012 at 2:19 PM, Yuval Shavit <yshavit at akiban.com> wrote:
> On Fri, Aug 17, 2012 at 3:07 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>> 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.
>
>
> How do you define "correct"? My point was that if you define it as

It's pretty subjective of course. Here's an extreme example

interface Iterator
    boolean hasNext() default{ return false; }
    Object next() default{ throw new NoSuchElementException(); }

your argument would have permitted it:) but it's clearly wrong.

I'm arguing that a default remove() impl feels wrong to me too.



> "conforming to the specified contract," then throwing UOE is *always*
> correct from the Iterator's perspective -- though it may not be correct and
> maximally useful. If you have a class whose iterator() method returns an
> Iterator with a more specific contract, then you as the implementer
> presumably know about that stronger contract and its implications on
> overriding your Iterator's remove().
>
> I happen to agree with you that it would have been nice to have something
> like Iterator <- ModifiableIterator, but that ship has sailed, and there's
> no point in re-opening the debate now. Given the current state of affairs, I
> think it's reasonable to provide Iterator.remove with a default
> implementation which is always correct, though not necessary desirable --
> and then to let implementers override it if they want to add additional,
> also-within-the-contract behavior.