Re: iterators
Daniel Pitts wrote:
Eric Sosman wrote:
Daniel Pitts wrote:
[...]
What I would *love* is an iterator that can be made smart enough to
not throw ConcurrentModificationException if the modification can be
proven to be non-conflicting (such as appending to a list, or
removing a node from a linked-list, which is not any node being
pointed to by the iterator.)
Can you give some examples of situations where you've wished you
had such a thing?
I have a simulation involving robots which can shoot at each other. Once
a robot is destroyed, it is removed from the list. At the time that
damage is dealt, I am already iterating through that list.
This means that I must go through the list afterward and remove the dead
robots, instead of removing them as they die.
This is a simplified example. The list itself may contain other objects
(such as missiles, mines, etc...) each of which may cease to exist
and/or inflict damage at any time.
Okay, but why is removal-en-passant not a "conflict?" It could
change what the Iterator's next() method delivers -- it could even
cause next() to throw NoSuchElementException after hasNext() has
already returned true!
Your ban against removing nodes "pointed to" by an Iterator may
avoid the problems I mention -- but if so, I don't see how it makes
your code any simpler. To avoid deleting the next() List element,
you'd have to make sure no Robot destroys its one-higher neighbor
Robot, or treat that destruction as a special case. So you're
still stuck with a mark-and-remove-later strategy, or some other
strategy that doesn't alter the List "now."
--
Eric.Sosman@sun.com