On 25 Sep 2015, at 14:00, Tagir F. Valeev <amae...@gmail.com> wrote:
> Hello!
>
> Quite interesting and long awaited features (at least according to
> StackOverflow questions).
All of them? or just the first?
> Isn't it a good idea to provide also a way
> to transfer between Optional types like "mapToInt", "mapToObj", etc.,
> like it's done in Stream API?
>
I don’t wanna go there, my response is transform Optional* into a *Stream. An
argument for adding mapOrElseGet (notice that the primitive variants return U)
is that other functionality can be composed from it.
> PS> 2) add to all variants a mapOrElseGet (otherwise known as a
> PS> “fold”), which is the equivalent of
> PS> map(mapper).orElseGet(supplier). That is arguably less
> PS> mind-bending to use when transforming from Optional<T> to Optional<U>.
>
> The proposed implementation is the following:
>
> public<U> U mapOrElseGet(Function<? super T, ? extends U> mapper,
> Supplier<? extends U> supplier) {
> if (!isPresent()) {
> return supplier.get();
> } else {
> return mapper.apply(value);
> }
> }
>
> It documents that:
>
> * @throws NullPointerException if the mapping function or the supplying
> * function is {@code null}
>
Thanks, yes, i need to update that to be consistent with the existing
functional accepting termination methods.
> However in fact it throws not always. For example, this call will not
> throw:
>
> Optional.empty().mapOrElseGet(null, () -> "x");
>
> To me it seems that this should be fixed (possibly adding
> requireNonNull checks) as it could become the source of silent bugs.
> Also you say that it's equivalent to the map().orElseGet() chain.
> However this one throws:
>
> Optional.empty().<String>map(null).orElseGet(() -> "x");
>
> There's also another problem. The orElseGet(null) is documented to
> work to work fine for non-empty optional
> (why on the Earth it was specified this way?).
Arguably it was a mistake that we did not catch in the frenzy of Java 8 feature
freeze. I would like to revert it but existing code might already be reliant on
it :-(
Paul.
> So there's good question whether the "supplier"
> argument of "mapOrElseGet" should be allowed to be null for non-empty
> optional (to conform with "orElseGet") or should not be allowed (to
> conform with "mapper" argument).
>
> With best regards,
> Tagir Valeev.
>
