opennlp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Kosin <>
Subject Re: Iterator vs. Streams
Date Fri, 28 Jan 2011 23:37:17 GMT
On 1/28/2011 8:48 AM, Jörn Kottmann wrote:
> On 1/28/11 11:06 AM, Steven Bethard wrote:
>> Again, I'm not asking for Iterators*instead of*  whatever custom
>> protocol you want to design. I'm asking for them*in addition to*  your
>> protocol.
> Lets think this one trough for a minute.
> We define a new RuntimeException, maybe named
> IORuntimeException.
> And an interface which implements java.util.Iterator:
> // All methods will throw IORuntimeException when
> // I/O errors occur.
> interface CloseableIterator extends java.util.Iterator {
>   void close();
> }

Lets even take your argument to the level you are talking about.... then
why doesn't Java implement all file I/O as an Iterator and get rid of
the implementation they already have for file I/O?

File I/O isn't nice to be iterating through; because (1) in order for
you to know if there is a next you would have to read the stream... and
save the result somewhere.... and (2) iterators were never meant to be
closed, they just get destroyed forcing us to create new iterators every
time we wanted to open the same file.
Really, the iterator idea may be good when we have already read the line
or in the process or parsing information out of the text; but, Java
already has iterators for those things.  We wouldn't need to recreate
those types of iterators, just start using them.
Back to the first point, having to read in the hasNext() would cause us
to have to check also when someone does a next() before attempting to
read or return a value; because we don't want necessarily read from the
file again.  This has the side effect of forcing the user to ALWAYS use
hasNext() which some tend not to do on occasion.

Just my 2 cents,

View raw message