On Sat, 25 Jul 2009, Mike Schilling wrote:
Lew wrote:
Roedy Green wrote:
Iterator is more general. You could for example later modify the
producer to fetch records from a sequential file, without having
to
change the client.
The general rule is avoid giving your client any more power than
they absolutely need to get the job done.
I guess you're focusing on returning an Iterator, as opposed to
passing one in as an argument.
In the argument scenario you need more work to avoid the
concurrent
modification issues other respondents have mentioned.
Even in the return scenario, you might get more joy returning an
Iterable than an Iterator.
Like most of these questions, it depends on what you're really
doing.
If you're passing something that can be iterated over more than
once
(e.g. the children of a DOM Node), pass Iterable. If it can only
be
iterated over once and then it's gone (e.g. a series of SAX events
generated from an InputStream), pass Iterator.
You can probably tell that I've been doing a lot of XML programming
lately.
Do you have a way of getting an Iterable interface in the mix here
somewhere? I had a related, although simpler, problem recently, and
was very happy to be able to work an Iterable in, because i could
then
for-loop over it. If a DOM node can be iterated in several ways, it
can't be Iterable itself, but could you have its getChildren etc
methods return some sort of NodeSequence object which, while not
necessarily a full-blown List, was Iterable? Is there any reasonable
way to combine this with one-shotness?
We've got quite a bit of infrastructure built around DOMs. It
reutnrs only the children of an Element that are themselves Elements.
wouldn't be difficult.