If it turns out that nextOptional is problematic because of nulls in iterators, we could, at least in theory, change it to return null for null, empty for hasNext=false, and Optional.of(next()) for hasNext=true.
ajs6f > On Dec 6, 2017, at 9:23 AM, Andy Seaborne <[email protected]> wrote: > > 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 <[email protected]> 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) <[email protected]> >>> 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
