Which is why I think we ought to provide "orElse*" directly.

As we have it currently, ajs6f's argument for only nextOptional() is to provide "orElse" via Optional so the Optional must be the end of iteration. Then it can't be for nulls during iteration (the stream case see [1]).

Claude - this is the javadoc: point 3 is that ExtendedIterators do not return null for next() in this usage.

Do you have a suggestion for improving that?

 /**
    Answer with an {@link Optional}.
This operation assumes that the {@code ExtendedIterator} does not return null for {@code next()}.
   If it does,  {@code NullPointerException} is thrown.
   <ul>
   <li>If there is no next, return {@code Optional.empty()}
<li>If the next object exists, and is not null, return that in the {@link Optional}. <li>If the next object exists, and is null, throw {@code NullPointerException}
   </ul>
 */

    Andy

http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003274.html

On 06/12/17 14:07, ajs6f wrote:
I don't think nextOptional will ever return null, but I think you mean empty? 
If so, and IIUC, what you say was exactly my objection (see discussion in the 
PR) but as Andy pointed out there, the Model API doesn't ever actually return 
an ExtendedIterator with null values, so the method turns out to be usable in 
the only use case we have for it.

ajs6f

On Dec 6, 2017, at 5:57 AM, Claude Warren <cla...@xenei.com> wrote:

my reading of this is that nextOptional will return null at the end of the
iteration and that this is indistinguishable from a null in the iteration
unless hasNext() is called.  but calling hasNext() after a null only tells
you if the next item is present not if the last item was present, thus a
null at the end of the iteration may be lost.  It almost seems like you
need a lastRead() method to retrieve the last read object again.  It seems
like this construct will only be useful when there  are no nulls in the
iteration.

Claude

On Mon, Dec 4, 2017 at 3:59 PM, Andy Seaborne (JIRA) <j...@apache.org>
wrote:


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

Andy Seaborne commented on JENA-1427:
-------------------------------------

{{nextOptional}} added for release 3.6.0.

Proposal: close this JIRA for now, see how {{nextOptional}} works out and
revisit {{orElse*}} based on experience.

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)




--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Reply via email to