Those arguments sound convincing to me. I guess I would only prefer the
docs were less mysterious,
and in addition to saying "not to mix the two styles", they would
state the reasons, as you have here :-)
-Marshall
Thilo Goetz wrote:
Marshall Schor wrote:
It seems to me the only object of confusion arises when users use
next() to get an element and move to the next element, and then use
moveToPrevious, which as you say, may or may not work if the iterator
ended up "invalid" because the next() moved it past the last element.
So the only "improvement" I would think is wanted is to make the moveTo
operations work reliably in these kinds of cases. Is that hard to do?
-Marshall
What do you mean by "reliably"? Suppose I'm at the end of an iteration,
and I call moveToNext() 3 more times. How many times do I need to call
moveToPrevious() to make the iterator valid again? Does each iterator
implementation need to track that kind of information?
The problem is that this sort of thing is not part of the iterator
contract, and we have quite a few iterator implementations, for various
indexes etc. When an iterator !isValid(), all bets are off. You can
call moveToFirst(), moveToLast(), or moveTo(FS) to reset it.
hasNext()/next() were simply not designed for that kind of environment,
which is why I originally implemented a different interface. I think
that's why, for example, there's no previous() in that API. Suppose
you were to call next(), then previous(). What would the expected
result be? Would you expect to get the same element twice, or not?
I personally have no intuition.
So I'll stick with my earlier recommendation: don't mix the two styles.
If you just need to iterate from start to end, by all means use the
java.util.Iterator style. Else, use the FSIterator API.
--Thilo
