> You can call nextOptional() forever which is odd.
This is just as true of nextOrElse*, so they're not better in that regard.
I agree that the semantics don't really work here, and I think Claude is right
to point at Streams as the place Optional really fits (e.g. Stream::findFirst).
ExtendedI
What this all shows to me is that Optional for end of iterator is not
what Optional is for.
next() has two return paths: an object reference or
NoSuchElementException. Converting NSEE into Optional goes against the
intent of Optional (see the EG email). The argument of reusing
machinery woul
[
https://issues.apache.org/jira/browse/JENA-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280460#comment-16280460
]
Code Ferret commented on JENA-1439:
---
Never flippin mind. located the error. I missed the
[
https://issues.apache.org/jira/browse/JENA-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Code Ferret reassigned JENA-1439:
-
Assignee: Code Ferret (was: Andy Seaborne)
> graph queries fail to preserve text:query 'lang:xx'
[
https://issues.apache.org/jira/browse/JENA-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280342#comment-16280342
]
Code Ferret commented on JENA-1439:
---
I've spent quite a bit of time trying to chase down
[
https://issues.apache.org/jira/browse/JENA-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Code Ferret reassigned JENA-1439:
-
Assignee: Andy Seaborne
> graph queries fail to preserve text:query 'lang:xx' arg
> --
> methods to convert the iterator to a stream should be sufficient. And i
> believe that has been implemented
I would say that actually having streams from the API would be sufficient, but
we are a long way from that. (We should restart that thread about a potential
new API with immutability a
Is optional.get() == null an expected or acceptable solution? I supose it
might be in this case. However i am beginning to believe that streaming
operations should not be applied to iterators and rather that methods to
convert the iterator to a stream should be sufficient. And i believe that
has
[
https://issues.apache.org/jira/browse/JENA-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-1427.
-
Resolution: Done
Assignee: Andy Seaborne
Fix Version/s: Jena 3.6.0
> Add nextOrElse
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 wrote:
>
> Which is why I think
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 - th
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
[
https://issues.apache.org/jira/browse/JENA-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280215#comment-16280215
]
A. Soroka commented on JENA-1427:
-
+1
> Add nextOrElse() method in ExtendedIterator
>
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
nu
14 matches
Mail list logo
