RFR 8080418 Add Optional.or()
forax at univ-mlv.fr
Fri Sep 25 13:42:54 UTC 2015
----- 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.
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>
> 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(),
More information about the core-libs-dev