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