[jira] [Comment Edited] (JENA-1427) Add nextOrElse() method in ExtendedIterator

["A. Soroka (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16257380#comment-16257380 ] 

A. Soroka edited comment on JENA-1427 at 11/17/17 6:42 PM:
-----------------------------------------------------------

You can definitely convert any {{Iterator}} into a {{Stream}} client-side, and Jena even has convenience methods therefor: {{org.apache.jena.atlas.iterator.Iter.asStream(Iterator<T>)}}. 

But an {{Iterator}} isn't a {{Stream}} and they should be distinguished pretty clearly.

(This took me a long time to understand, and really I had to read what Brian Goetz wrote [here|https://www.ibm.com/developerworks/library/j-java-streams-3-brian-goetz/index.html] and then [~andy.seaborne] had to beat it into my head. The sentence (from that article) "When the terminal operation is initiated, the stream implementation picks an execution plan." speaks volumes about the difference in these abstractions. An {{Iterator}} generally doesn't "pick an execution plan".)

An {{Iterator}} is a source of inputs, a {{Stream}} is a _composition of functions_ attached to a source of inputs. If you don't believe me, take a look at the difference between something {{java.util.AbstractList.Itr<E>}} and something like {{java.util.stream.ReferencePipeline<P_IN, P_OUT>}}.

I really think this kind of functionality might best be left client-side but maybe you can send a PR with what you'd like and we can get more eyes on it?


was (Author: ajs6f):
You can definitely convert any {{Iterator}} into a {{Stream}} client-side, and Jena even has convenience methods therefor: {{org.apache.jena.atlas.iterator.Iter.asStream(Iterator<T>)}}. 

But an {{Iterator}} isn't a {{Stream}} and they should be distinguished pretty clearly.

(This took me a long time to understand, and really I had to read what Brian Goetz wrote [here|https://www.ibm.com/developerworks/library/j-java-streams-3-brian-goetz/index.html] and then [~andy.seaborne] had to beat it into my head. The sentence (from that article) "When the terminal operation is initiated, the stream implementation picks an execution plan." speaks volumes about the difference in these abstractions. An {{Iterator}} generally doesn't "pick an execution plan".)

An {{Iterator}} is a source of inputs, a {{Stream}} is a _composition of functions_ attached to a source of inputs. If you don't believe me, take a look at the difference between something {{java.util.AbstractList.Itr<E>}} and something like {{java.util.stream.ReferencePipeline<P_IN, P_OUT>}}.

I really think this kind of functionality might best be left client-sidel but maybe you can send a PR with what you'd like and we can get more eyes on it?

> Add nextOrElse() method in ExtendedIterator
> -------------------------------------------
>
>                 Key: JENA-1427
>                 URL: https://issues.apache.org/jira/browse/JENA-1427
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: Jena 3.5.0
>            Reporter: Adam Jacobs
>            Priority: Trivial
>              Labels: easytask
>
> Allow a functional approach for returning a default value or throwing a custom exception from a Jena iterator.
> The following method may be added to the ExtendedIterator interface.
> {noformat}
>     /**
>          Answer the next object, if it exists, otherwise invoke the _supplier_.
>      */
>     public default T nextOrElse( Supplier<T> supplier ) {
>         return hasNext() ? next() : supplier.get();
>     }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)