Default method survey results
forax at univ-mlv.fr
Fri Aug 17 13:48:07 PDT 2012
On 08/17/2012 09:32 PM, "Zdeněk Troníček" wrote:
> 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
>>>> 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
>> 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
It's better because you can now simply remove most of the method
remove() of the existing iterators.
> 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?
??, I don't understand why you get an exception at runtime.
More information about the lambda-dev