Iterator performance contract (and use on non-collections)

Posted by polygenelubricants on Stack Overflow See other posts from Stack Overflow or by polygenelubricants
Published on 2010-03-23T15:40:09Z Indexed on 2010/03/23 17:23 UTC
Read the original article Hit count: 389

Filed under:
|
|
|

If all that you're doing is a simple one-pass iteration (i.e. only hasNext() and next(), no remove()), are you guaranteed linear time performance and/or amortized constant cost per operation?

Is this specified in the Iterator contract anywhere?

Are there data structures/Java Collection which cannot be iterated in linear time?

java.util.Scanner implements Iterator<String>. A Scanner is hardly a data structure (e.g. remove() makes absolutely no sense). Is this considered a design blunder?

Is something like PrimeGenerator implements Iterator<Integer> considered bad design, or is this exactly what Iterator is for? (hasNext() always returns true, next() computes the next number on demand, remove() makes no sense).

Similarly, would it have made sense for java.util.Random implements Iterator<Double>?

Should a type really implement Iterator if it's effectively only using one-third of its API? (i.e. no remove(), always hasNext())

© Stack Overflow or respective owner

Related posts about java

Related posts about iterator