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. > >> 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.
