[
https://issues.apache.org/jira/browse/OPENNLP-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987564#action_12987564
]
Jörn Kottmann commented on OPENNLP-99:
--------------------------------------
ObjectStream has a read method which can retrieve an object from the stream. It
also declares an exception which can be thrown in case of an error.
In our experience over at the tools project it turned out that such a read
method style interface seems to be easier to use and implement in our cases.
When we made the decision we had a long discussion if we prefer an iterator
like interface a stream like interface
and we decided to take the stream like interface.
It is also a question of taste of course. Since both interface styles can do
the same.
Lets say we want to read every line in a file. The line should be represented
as a string.
With the stream interface its something like this.
In the read method we read until the end of the first line, and return it.
It is repeated if it is called again, when the underlying stream is exhausted
null is returned.
User expects read method to maybe block shortly if underlying system is slow.
Iterator like interface.
User calls hasNext() to determine if there is one more item. Implementation
must now read
the first line inside hasNext() and then return the result from next() which
seems less clear
und less intuitive to me. User does not really know which of the two methods
will block.
InputStreams/Readers must be adapted to this interface, but are naturally easy
to use with
the stream style interface.
In the end we had the feeling that stream style interface is a bit simpler and
more intuitive to use.
> EventStream should extend Iterator<Event>
> -----------------------------------------
>
> Key: OPENNLP-99
> URL: https://issues.apache.org/jira/browse/OPENNLP-99
> Project: OpenNLP
> Issue Type: New Feature
> Components: Maxent
> Affects Versions: maxent-3.0.0-sourceforge
> Reporter: Steven Bethard
>
> [As requested, brought over from Sourceforge.]
> Conceptually, EventStream is just an Iterator<Event>. You would get better
> interoperability with other Java libraries if EventStream were declared as
> such. If you didn't care about backwards compatibility, I'd say just get rid
> of EventStream entirely and use Iterator<Event> everywhere instead.
> If you care about backwards compatibility, you could at least declare
> AbstractEventStream as implementing Iterator<Event> - it declares all of
> hasNext(), next() and remove(). I believe that shouldn't break anything, and
> should make all the current EventStream implementations into Iterator<Event>s.
> Why do I want this? Because, when using OpenNLP maxent from Scala, if a
> RealValueFileEventStream were an Iterator<Event>, I could write:
> for (event <- stream) {
> ...
> }
> But since it's not, I instead have to wrap it in an Iterator:
> val events = new Iterator[Event] {
> def hasNext = stream.hasNext
> def next = stream.next
> }
> for (event <- events) {
> ...
> }
> Or write the while loop version:
> while (stream.hasNext) {
> val event = stream.next
> ...
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
