Closed GoogleCodeExporter closed 8 years ago
Oh, I see you ended up having ImmutableCollection's iterator() method return an
UnmodifiableIterator. I see no harm in factoring it in a superclass, if for
example one
implements an immutable container but would rather not implement size(),
contains()
etc, but granted, I don't see major benefit from this either.
Original comment by jim.andreou
on 29 Oct 2009 at 7:34
We considered this once and we weren't clear on the major benefits either,
which made
it feel gratuitous. Also, it's potentially ambiguous, since 'collection
instanceof
UnmodifiableIterable' doesn't imply that it's an unmodifiable collection (only
that it
can't be modified via its iterator).
Original comment by kevin...@gmail.com
on 29 Oct 2009 at 7:51
Original comment by kevin...@gmail.com
on 30 Oct 2009 at 4:01
I was just about to start a new issue for that.
I want to argue in favour of UnmodifiableIterable for two reasons I see as major
benefits:
- consitency: If you sprinkle Unmodifiable* and Immutable* all around your code, it
is better to have a clear marker interface that states that a returned iterable
is
unmodifiable as well. Furthermore seeng it in a method signature is a clear
statement
that the method is not going to try invoking remove on the itarebles iterator.
- Principle of least surprise. If your clearly type all return values as
UnmodifiableIterable and get only a UnmodifiableIterator out of it, you will
never be
tempted to use it wrong.
Please reconsider adding the Type.
Original comment by marcus.t...@gmail.com
on 1 Nov 2009 at 10:03
Original issue reported on code.google.com by
jim.andreou
on 29 Oct 2009 at 7:12