Note that the original request in Jena-1427 was for a nextOrElse() method accepting an instance of Supplier<T>. The implementation of nextOptional(), released in version 3.6, solves my use case just as well.
The only reason I had not requested nextOptional() directly is that ExtendedIterator was already composed of custom functional-programming-oriented methods. In my experience, the API of ExtendedIterator is superior (i.e. more user friendly) than what Java 8 offers in its Streams, so I thought it was worth considering alternatives. For me, there is no wrong choice here as any of several options solve my problem. I appreciate everyone who has contributed to the discussion. ________________________________________ From: ajs6f <[email protected]> Sent: Sunday, December 17, 2017 1:28 PM To: [email protected] Subject: Re: Jena-1427 - nextOptional() > On Dec 17, 2017, at 2:18 PM, Claude Warren <[email protected]> wrote: > It seems that much of the rest of the discussion is covered by adding a > method to convert the iterator to a stream (probably just a call to an > existing Java method. Just to this point alone-- this is something that came up _in_ the discussion (we even already have Iter::asStream for the purpose), and I don't agree with it. Converting an iterator to a stream is a useful thing, to be sure, but although it doesn't really speak to the optimizations that people (rightly) associate with a stream (i.e. it doesn't push filters or other computations back to whatever they might look like closer to the source of elements) it does create a bunch of objects and machinery. I'd rather not encourage people to do this-- I'd rather encourage them to use plain iterators unless/until we can actually supply an API with real streams. Otherwise: > Perhaps we should add a next( T default ) method that will return the default > if hasNext() returns false. This seem better than polluting the environment > with Optionals that don't really belong. I don't agree at all that Optional doesn't belong here, but if the original requestor can confirm that this would meet the use case, and if we can come up with something for throwing a custom exception that does pass Claude's "smell test", then I'm fine with it. I'd rather not add method after method to ExtendedIterator for every possible syntactic convenience. (This ain't Scala! :wink:) ajs6f > On Dec 17, 2017, at 2:18 PM, Claude Warren <[email protected]> wrote: > > From the original request it seems the requirements were: > 1. return a default value if the iterator is empty. > 2. throw a custom exception if the iterator is empty. > > > Perhaps we should add a next( T default ) method that will return the > default if hasNext() returns false. This seem better than polluting the > environment with Optionals that don't really belong. > > If we want to provide a method to throw an custom exception we could add > something like next( Class<? extends Exception> e ) to create and throw the > exception. But I don't like this one for some reason. Like the Optional > it doesn't pass the smell test for me. > > It seems that much of the rest of the discussion is covered by adding a > method to convert the iterator to a stream (probably just a call to an > existing Java method. > > Claude > > > On Sun, Dec 17, 2017 at 5:50 PM, Andy Seaborne <[email protected]> wrote: > >> We seem to have drifted a bit here - the original use case wasn't about >> streaming as I read it. list* get used to write zero/one tests and one/many >> tests dealing with properties etc. >> >> And, of course, we want to avoid the anti-pattern of Optional/if-empty. >> >> Claude - thoughts on the use case? How might we evolve the current API >> without method bloat? >> >> Andy >> >> >> On 14/12/17 17:46, Claude Warren wrote: >> >>> I was expecting that with the discovery that optional throws a null >>> pointer >>> exception when the retrieved value is null would be enough to remove this >>> functionality. >>> >>> I am concerned that once added it will be difficult to remove and that its >>> operation is not congruent with stream based optional usage. >>> >>> Claude >>> >>> On 14 Dec 2017 10:33, "Andy Seaborne" <[email protected]> wrote: >>> >>> Claude, >>>> >>>> The JIRA ticket ends: >>>> >>>> [[ >>>> ASF GitHub Bot added a comment - 04/Dec/17 15:36 >>>> >>>> That was already the case in the PR and I've added text to call it out >>>> explicitly into the javadoc. >>>> ---- >>>> githubbot ASF GitHub Bot added a comment - 04/Dec/17 15:40 >>>> >>>> Github user ajs6f commented on the issue: >>>> >>>> https://github.com/apache/jena/pull/323 >>>> >>>> Okay, that works for me! >>>> ---- >>>> Andy Seaborne added a comment - 04/Dec/17 15:58 >>>> >>>> nextOptional added for release 3.6.0. >>>> >>>> Proposal: close this JIRA for now, see how nextOptional works out and >>>> revisit orElse* based on experience. >>>> ---- >>>> ajs6f A. Soroka added a comment - 1 week ago >>>> >>>> +1 >>>> ]] >>>> >>>> Adding nextOptional, and no others, is in the RC. >>>> >>>> What were you expecting? >>>> >>>> Andy >>>> >>>> On 14/12/17 08:44, Claude Warren wrote: >>>> >>>> Perhaps i wasn't paying close enough attention but i didn't think adding >>>>> optional and other streaming methods had been agreed. In fact i thought >>>>> quite the oposite. >>>>> >>>>> If i am wrong please forgive the noise. If i am correct shouldn't 1427 >>>>> be >>>>> removed from the release candidate? >>>>> >>>>> Claude >>>>> >>>>> >>>>> >>> > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
