Re: Exception Names
Alan Gutierrez wrote:
On Mar 29, 11:32 am, Arne Vajh?j <a...@vajhoej.dk> wrote:
Mike Schilling wrote:
Arne Vajh?j wrote:
Mike Schilling wrote:
Since we're not
assuming
any asynchrony, I'd expect hasNext() to do actual I/O, if that's
necessary to ensure that a character is available.
I don't think that is intuitive.
It is to me (how do you know whether there's a next character if you
don't fetch it?), but perhaps that's because I've implemented a lot of
iterators where hasNext() had to do significant work.
I have seen it too, but from an ultra strict puristic view then
hasXxxx should not change the state of an object.
Indeed, the Iterator interface doesn't apply because it is supposed to
be an iterator over the state of an object. The read method does
change the state of a stream, which is why I/O streams are their own
library, with their own patterns. The read method is not an iterator,
it reads, it goes to I/O and comes back with a result, and one valid
result is that there is nothing there.
We know that it is not an iterator. The discussion is whether it
could be made one.
Is hasNext supposed to block? Where is there support for that in
Iterator? How would I set a timeout?
Given how java.io works and what would make sense, then I would
say block and no timeout.
But yes - this is another potential problem.
Even if we managed to hammer out how to implement Iterator over an
InputStream, now how do we implement the other flavors of read? Does
an InputStream somehow generate a Iterator<List<Byte>> to replace
InputStream.read(byte[])?
I don't think those would fall under the iterator hat.
But it is a rather hypothetical discussion. It will not happen. For
good reasons.
Arne