RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong

[Joe Bowbeer]

In this case, I do not favor the addition. I'll believe the Option lovers
that Options are cool and that our version is good enough.

The alternative is OK too but I think it would be worse to include both as
long as our Option is good enough. If our Option is not good enough then we
should adopt the alternative instead.

So far, in my one limited use (findFirst) or Optional works OK.

Still wondering about equals and hashCode...
 On Mar 6, 2013 11:34 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> For Option lovers, one way to view this: it enables someone to provide
> their own Option instead of the one we provide. Right? If not, then I'm
> less favorable.
>
> No, not right.  It prevents people from distinguishing between a stream
> that is empty and a stream containing only the "orElse" value.  Just like
> Map.get() prevents distinguishing between "not there" and "mapped to null."
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130306/0e77be87/attachment.html