Greg Trasuk wrote:
On Thu, 2010-07-22 at 14:46, Gregg Wonderly wrote:
Ok, didn't think of that, still using the old for loop.
I think the subtle issue that Peter was getting at though, is that Iterator has
the "remove()" method which perhaps should not be a published behavior, since it
implies an API that is not currently in the design of the system. I'm not that
bothered by this in an internal API, but in some cases, you have to be careful,
and perhaps pass a copy, as in
new ArrayList<Task>( ... ).interator()
just to make sure that your original collection is not compromised by other
software.
'remove()' is an optional operation. You can just take the original
Iterator and wrap it inside an Iterator that delegate next() and
hasNext() to the original, but throws UnsupportedOperationException on
everything else.
Matter of fact, I wouldn't be surprised if
java.util.Collections.unmodifiableCollection(...) does pretty much that.
Yes, I just wanted to point at that if you had not controlled this issue in some
way, it may come back to bite you. Adding the "RuntimeException" into the mix,
can be a good thing, but often, doing this after the fact is a bad thing because
you then discover external users that are doing remove(), in a not so good way
when the thread dies or otherwise starts behaving strange.
I would of preferred an interface such as
public interface MutableIterator<T> extends Iterator {
public void remove();
}
had been defined. We are learning more and more, the power of immutability, and
calling it out in the name space, for me, is a good thing.
Gregg Wonderly
