RFR 8080418 Add Optional.or()
Paul Sandoz
paul.sandoz at oracle.com
Fri Sep 25 13:29:36 UTC 2015
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.
>
>> Separately while we are on the topic of Optional i would be interested in opinions on the following changes:
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/optional-prims-filter-map/webrev/
>>
>> 1) add methods that were missing on the primitive specializations; and
>
> Seems fine, although I think a good case can be made for mapToObj() -
> while going via a stream is possible, it is non-intuitive. I don't
> think mapToInt() or mapToLong() are necessary on OptionalDouble (and
> so on), but not being able to reach Object will be restrictive..
>
I doubt that such operations are so very common to justify a spread of "box/unbox" methods transforming between the optional variants. Also I don’t want to pollute Optional with Optional*, especially looking forward when the primitive variations can be deprecated.
It’s also possible to do so via map.orElseGet or a “fold”.
>> 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.
Paul.
More information about the core-libs-dev
mailing list