RFR 8080418 Add Optional.or()

[Remi Forax]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 25 Septembre 2015 15:29:36
> Objet: Re: RFR 8080418 Add Optional.or()
> 
> 
> On 25 Sep 2015, at 15:06, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> > On 25 September 2015 at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> >> Please review this change to add a method Optional.or that allows one to
> >> better compose optionals:
> >> 
> >>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
> > 
> > New method seems fine.
> 
> Thanks.

yes, or() is Ok !

[...]

> 
> >> 2) add to all variants a mapOrElseGet (otherwise known as a “fold”), which
> >> is the equivalent of map(mapper).orElseGet(supplier). That is arguably
> >> less mind-bending to use when transforming from Optional<T> to
> >> Optional<U>.
> > 
> > To me, this is pointless, and makes the API more confusing. Chaining
> > methods is a way of life in Java 8, and developers have to be able to
> > think that way.
> 
> It’s not about chaining it’s having to reason about Optional<Optional<>>,
> which is one reason for “Optional.or” e.g.:
> 
>   Optional<String> a = Optional.of("A");
>   OptionalInt c = a.map(s -> OptionalInt.of(s.length())). // Optional<OptionalInt>
>           orElseGet(OptionalInt::empty);
> 
> The “fold” is essentially a core building block.

maybe you should add a note in ifPresentOrElse() noticing that the non 'void' version is called orElseGet(),

> 
> Paul.
> 

Rémi