Libraries updates for extensions methods

"Zdeněk Troníček" tronicek at
Tue Aug 14 03:22:47 PDT 2012

"Reading is more important than writing." Not only on language level.
Which of these two is easier to understand for you when you read it?

public Iterator<String> iterator() {
    return new Iterator<String>() {

public Iterator<String> iterator() {
    return new ImmutableIterator<String>() {

Zdenek Tronicek
FIT CTU in Prague

Brian Goetz napsal(a):
> It would have been better to do this from the beginning, but I think
> this ship has mostly sailed.  There are three choices:
>   - II extends I
>   - I extends II
>   - Neither extends each other
> The third choice is a failure because they can't be interchanged with
> existing APIs.
>  From a strict method-subsetting perspective, I should extends II.  But
> that would violate the contract of immutability inherent in the name.
> An abstract class ImmutableIterator with a final throwing remove method
> might be a reasonable implementation convenience.  But putting a default
> on remove is better, since it doesn't burn your single class inheritance
> slot just to get a trivial implementation of remove.
> On 8/13/2012 12:12 PM, "Zdeněk Troníček" wrote:
>> Concerning the Iterator, I was always curious why there is not any class
>> ImmutableIterator with method remove() throwing UOE.
>> I found 89 implementations of Iterator in JDK 7.
>> 35 of them implements remove() as { throw new UOE(); }.
>> 29 out of these 35 implement directly Iterator, 6 implement
>> ListIterator.
>> 34 out of 35 could use ImmutableIterator or ImmutableListIterator
>> because
>> they are either anonymous subclasses or classes that do not have any
>> explicit superclass.
>> Only once (CorbaContactInfoListIteratorImpl) this is not possible.
>> Wouldn't be the class ImmutableIterator more stylish?
>> (The numbers are without any warranty. I have not done any double
>> check.)
>> Z.

More information about the lambda-dev mailing list