Default method survey results

[Rémi Forax]

On 08/17/2012 09:32 PM, "Zdeněk Troníček" wrote:
> Rémi Forax napsal(a):
>> On 08/17/2012 07:27 PM, Zhong Yu wrote:
>>>> 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.
>>
> Why is it better? The only argument that appeared here was that you can
> inherit it without burning the inheritance slot. But it is not relevant in
> this particular case because iterators are typically simple nested
> classes. And they should be when you follow the single-responsibility
> principle.

It's better because you can now simply remove most of the method 
remove() of the existing iterators.

> On the hand, it seems worse when you implement an iterator. You implement
> all abstract methods, the code compiles without any warning, and then you
> get an exception at runtime. Isn't that anything we want to prevent from?
>
>

??, I don't understand why you get an exception at runtime.

Rémi