RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong
tim at peierls.net
Wed Mar 6 09:50:18 PST 2013
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts