Default method survey results

[Zhong Yu]

On Fri, Aug 17, 2012 at 1:40 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> 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

interface IteratorAndRemover extends Iterator

Proliferation of types isn't a good thing, but if an operation is very
rare, it's justifiable to move it to another type.

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