RFR 8080418 Add Optional.or()

[Paul Sandoz]

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.