Is an “infinite” iterator bad design? [closed]

Answer 1

Yes. You just need a different criteria for when to stop iterating.

The concept of infinite lists is very common in lazy evaluation languages like Haskell and leads to completely different program designs.

Answer 2

The whole point of an Iterator is that it is lazy, i.e. that it gives you only as many objects as you ask for. If a user asks for all objects of an infinite Iterator, it's their problem, not yours.

Answer 3

Consider whether you have a generator function. An iterator may be a reasonable interface to a generator, or it might not, as you've noticed.

On the other hand, Python has generators which do terminate.

Answer 4

It is a perfectly legitimate use - as long as it is properly documented.

Using the name CyclicIterator is a good idea, as it infers that looping on the iterator might well possibly be infinite if the loop exit case is not properly defined.

Answer 5

If you have an object that needs an iterator, and you happen to give it an infinite iterator, then all should be well. Of course, that object should never require the iterator to stop. And that is the potentially bad design.

Think of a music player. You tell it to start playing tracks in "continuous play mode" and it plays tracks until you tell it to stop. Maybe you implement this continuous play mode by shuffling a playlist forever... until the user presses "stop". In this case, MusicPlayer needs to iterator over a playlist, that might be Collection<Track>, forever. In this case, you'd want either a CyclicIterator<Track> as you've built or a ShuffleIterator<Track> that randomly picks the next track and never runs out. So far, so good.

MusicPlayer.play(Iterator<Track> playlist) wouldn't care whether the play list ends or not. It works both with an iterator over a list of tracks (play to the end, then stop) and with a ShuffleIterator<Track> over a list of tracks (pick a random track forever). All still good.

What if someone tried to write MusicPlayer.playContinuously()--which expects to play tracks "forever" (until someone presses "stop"), but accepts an Iterator<Track> as the parameter? That would be the design problem. Clearly, playContinuously() needs an infinite Iterator, and if it accepts a plain Iterator as its parameter, then that would be bad design. It would, for example, need to check hasNext() and handle the case where that returns false, even though it should never happen. Bad.

So implement all the infinite iterators you want, as long as their clients don't depend on those iterators ending. As if your client depends on the iterator going on forever, then don't give it a plain Iterator.

This should be obvious, but it doesn't seem to be.

Answer 6

An infinite iterator is very useful when you create infinite data, e.g. linear recurrent sequences like the Fibonacci sequence.

So it is totally fine to use such.