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: 386
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