Primitive streams and optional (original) (raw)

Tim Peierls tim at peierls.net
Tue Nov 27 06:33:05 PST 2012

On Tue, Nov 27, 2012 at 5:22 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

On Nov 26, 2012, at 10:12 PM, Sam Pullara <spullara at gmail.com> wrote: > I think I like 3 (or is this 4?) with additional methods that use suppliers for the cases where it isn't clear what we should do rather than Optional. Something like: > > T findFirst(Callable notFound) > > Have we explored solutions like that? We could always override the method with one that has a well defined behavior in the miss case: > > T findFirst() // throws NoSuchElementException on failure

I still prefer having one method that returns a "thing" that can be used, uniformly and in a fluent-like manner, to do determine whether a result is available or absent.

Me, too, if by "thing" you mean "Optional". It solves so many problems: Strongly discourages use of null as a stream element, avoids user errors stemming from the use of null as a sentinel value, makes code easier to read, makes stream docs easier to read (by moving the available/absent stuff elsewhere).

What are the drawbacks? Potential for overuse, as in Optional<Optional>. Creation of an intermediate object. Both drawbacks outweighed, imho, by the benefits.

--tim

More information about the lambda-libs-spec-observers mailing list