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

[Sam Pullara]

I am for removing it and in favor of providing a default if it doesn't have nearly the same functionality as the Scala Option. The way Optional is written right now I would tell people not to use it anyway and it would just be a wart on this API.

Sam

On Mar 6, 2013, at 9:50 AM, Tim Peierls <tim at peierls.net> wrote:

> On Wed, Mar 6, 2013 at 7:09 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>  T findFirst(Predicate<? super T> predicate, T ifNone);
>  T findAny(Predicate<? super T> predicate, T ifNone);
> 
> People wanting to avoid Optional can then then
> get all of the derived versions (allMatch, plain
> findAny, etc) easily enough.
> 
> Surprisingly enough, that's the only missing
> feature that would otherwise enable a completely
> Optional-free usage style of the Stream API.
> 
> We have both proposed variants of this several times,
> but they don't seem to go anywhere. It would be nice
> to have a calm final discussion about why we would NOT
> do such an apparently sensible thing!
> 
> I've had too much coffee to be calm, and I have no way of ensuring finality, but the foremost reason I see for not allowing an Optional-free usage style is that people will adopt it rather than use Optional. They will see it as a license to put null everywhere, and they'll get NPEs way downstream and blame it on Java.
> 
> Optional should be (and currently is) a very limited abstraction, one that is only good for holding a potential result, testing for its presence, retrieving it if it is present, and providing an alternative if not. We should resist the temptation to make it into something more or make it into a knock-off of the similar Scala type.
> 
> --tim
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130306/64f3ca62/attachment-0001.html