On 27/04/2013 1:46 AM, Paul Sandoz wrote:
On Apr 26, 2013, at 4:37 PM, Peter Levart <peter.lev...@gmail.com> wrote:
Another "interesting" usage:
Iterator<?> i = ...;
i.forEachRemaining(e -> {
...
if (...) {
i.forEachRemaining(dummy -> {}); // drain it
}
...
});
It seems that mixing external and internal iteration in the same object is like
a box of chocolates. For internal iteration, Iterable.forEach is more suitable
than Iterator.forEachRemaining unless the later is specified to have the common
state for both external and internal iteration, which means that internal can
not be more effective than external.
Similar observations can apply to Spliterator as well. IIRC many
spliterator.forEachRemaining implementations set up state to be fully traversed
before looping. However, it is not possible in all cases.
I think we may have to document that a consumer must not interfere with the
current traversal otherwise behaviour is undefined.
Maybe my thinking is not creative enough but to me a method on Iterator
called forEachRemaining(f) has very clear semantics:
while (it.hasNext()) {
f.accept(next());
}
at completion the Iterator is "consumed" there are no elements left.
If f.accept messes with the iterator then it is probably best left
unspecified as to what might, or might not happen. Then again perhaps
the interaction of all Iterator methods should be fully spelt out - and
if we think that is a problem maybe adding methods to Iterator is not
such a great idea.
But I think this needs to go back to the expert list, if not already there.
David
Paul.
