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
