Default method survey results

[Rémi Forax]

On 08/17/2012 07:27 PM, Zhong Yu 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.
>
> Zhong Yu

No, it was not a mistake to include remove(), this is the only way to 
iterate
over a set and remove elements in a safe way, the mistake was more to 
not provide
an abstract class, but now that we have a way to put code in interface,
it's a better that providing an abstract class.

Rémi