Default method survey results

[Rémi Forax]

On 08/18/2012 09:35 AM, "Zdeněk Troníček" wrote:
> 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
>>> 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.
> 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.

Just, my gut feeling which is certainly biased because I've recently 
spend too much time seeing API that leverage lambdas like Guava, 
gs-collection, etc.

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

given that AbstractCollection already exists that's true that there is 
less need,
this is less clear for List/AbstractList because AbstractList embodies 
the failfast implementation,
so there is currently code duplication between AbstractList and all 
lists of java.util.concurrent.

>
> 2) Iterator with remove() that throws UOE breaks the Liskov substitution
> principle. Mutable iterator is not a special case of immutable iterator.

You move the discussion from implementation to concepts, to types,
you can't really create an immutable iterator interface because you 
can't retrofit the code that use Iterator without breaking binary 
compatibility.
And about the Liskov substitution principle, the whole OOP is just a way 
to twist the application to fit into an object model, so depending on 
your application, one can be a subtype of the other.

>
> 3) (from my previous emails) The same can be implemented in a more
> Java-stylish way.

Note that your solution also doesn't preserve the serialization format ...
Note that don't I care too much about the kind of applications that are 
written with serializable iterators.

>
> Z.

Rémi