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

[Remi Forax]

On 03/06/2013 01:09 PM, Doug Lea wrote:
> (Restricting to lambda-libs list...)
>
> On 03/06/13 04:47, Remi Forax wrote:
>> Ok, let be nuclear on this,
>> There is no good reason to introduce Optional<T> in java.util.
>
> We agree about most of the rationale for not using Optional.
> But there are still people who say they want it.
> I don't think it is productive at this point to
> argue about features supporting an Optional-laden
> programming style. But we never seem to hit closure
> about features supporting an Optional-free style.

Hi Doug,
while I agree that it's not productive to hope that people will not use 
Optional.
like the status quo, Optional or Option are defined in Scala lib or in 
Guava lib
and users can opt-in if they want.

The design I propose let Guava by example to provide a simple 
Optionalizer (again not a good name), that returns an Optional.
Something like
   Optional<String> s = stream.findFirst(asOptional());

with asOptional defined like this:

public static <T> Optionalizer<T, Optional<T>> asOptional() {
   return (isPresent, element) -> isPresent? Optional.of(element): Optional.absent();
}

cheers,
Rémi

> So I'd like to re-propose a simple compromise.
> In the same way that there are Optional and
> basis-returning versions of reduce:
>
>  T reduce(T identity, BinaryOperator<T> reducer);
>  Optional<T> reduce(BinaryOperator<T> reducer);
>
> (Where the basis-returning one can in turn be used to
> avoid Optional-returning min(), etc). We should do the
> same at least for find, or  more in keeping with current
> API, findFirst and findAny:
>
>  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!
>
> -Doug
>