Libraries updates for extensions methods

["Zdeněk Troníček"]

"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>() {
        ...
    }
}

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