----- Mail original -----
> De: "Paul Sandoz" <paul.san...@oracle.com>
> Cc: "core-libs-dev" <core-libs-dev@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 <scolebou...@joda.org> wrote:
>
> > On 25 September 2015 at 11:58, Paul Sandoz <paul.san...@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
