Default method survey results

"Zdeněk Troníček" tronicek at
Fri Aug 17 12:32:14 PDT 2012

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

More information about the lambda-dev mailing list