[
https://issues.apache.org/jira/browse/OPENNLP-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987558#action_12987558
]
Steven Bethard commented on OPENNLP-99:
---------------------------------------
Ahh, the curse of checked exceptions bites again. I'm not sure how ObjectStream
helps - could you explain? Looks like ObjectStream isn't an Iterator either.
I see two relatively simple solutions:
(1) Give up on checked exceptions and declare the interface with runtime
exceptions instead:
public class OpenNLPIOException extends java.lang.RuntimeException {...}
public interface EventStream extends Iterator<Event> {
public Event next() throws OpenNLPIOException;
public boolean hasNext() throws OpenNLPIOException;
...
}
You still get all errors reported if something goes wrong, and people can still
catch and handle those errors if they want to. Of course, Java will no longer
force you to handle them at compile time. And you wouldn't be using a standard
exception type.
(2) Add a method AbstractEventStream.asIterator() that looks something like:
public Iterator<Event> asIterator() {
return new Iterator<Event>() {
public boolean hasNext() {
try {
return this.hasNext();
catch (IOException e) {
throw new RuntimeException(e);
}
}
public Event next() {
...
}
...
}
Here, we're no longer using the standard Java Iterator interface, but this
would allow you to keep EventStream as it is, but still make it easy for users
to get an Iterator from most EventStreams if they wanted one.
> 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.
