Default method survey results
tronicek at fit.cvut.cz
Sat Aug 18 00:35:37 PDT 2012
Rémi Forax napsal(a):
> On 08/17/2012 09:32 PM, "Zdeněk Troníček" wrote:
>> 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
>> this particular case because iterators are typically simple nested
>> classes. And they should be when you follow the single-responsibility
> It's better because you can now simply remove most of the method
> remove() of the existing iterators.
Could you share the reasons for this statement? I expect you analyzed some
sufficiently large code base and the results show that most iterators are
read-only. This sounds suprising especially when I confront it with my
quick analysis of Java platform code which I sent recently.
However, even if it was true I do not think this per se could have
justified such change. On the other hand, I see a few reasons against:
1) Consistency with the rest of java.util. Iterator.remove() is not the
only optional operation in java.util. For example, Collection has 6
optional operations which are implemented in AbstractCollection. I do not
expect you to propose moving them to Collection since we (hopefully)
agreed upon that the abstract class is better than default methods here.
2) Iterator with remove() that throws UOE breaks the Liskov substitution
principle. Mutable iterator is not a special case of immutable iterator.
3) (from my previous emails) The same can be implemented in a more
FIT CTU in Prague
More information about the lambda-dev