Where has the map method on Optional moved?

[Paul Sandoz]

On Feb 26, 2013, at 12:33 PM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
> FlatMapper is a bizarre Frankensteinian beast, relying as it does on
> mutation to do all of its things.

You mean mutation as in mutation of state? or mutation in the sense of Frankensteinian mutation due to indirection?


> It would be a service to all to
> rename it to something – anything – else, as it does not resemble the
> notion of flatMap/bind that other functional programming languages or
> libraries implement.
> 
> As to consistency across the interfaces, Java doesn't have the ability
> to generalise across Optional and Stream, lacking Higher Kinded Types.
> The fact that Stream has named some feature that resembles a monadic
> bind flatMap ideally should not then preclude the ability for Optional
> to also have this feature.
> 
> As to additional potential functionality, you are quite correct, the
> restriction of inheritance/OO to be the sole mechanism for adorning
> functionality on a data-structure means that the temptation exists to
> implement it directly, and these (filter/fold/reduce/foreach etc) are
> all sensible suggestions. I do not profess to have definitive answers
> to these library design decisions, given the constraints that the
> designs are under.

The problem being Optional would stick out like a sore thumb. It's not a Stream. There is no direct way to get a Stream from it and if there were, which is quite easy to do, it would not give you what you really want.



> I am nevertheless obligated to point out that these
> things _are_ monads, or that they form applicative functors – these
> are just simple properties that arise from the data-structure.
> 
> My personal preference would be to attempt to give Optional as much of
> the functionality it can support – that has been what we've tried to
> do with our version*. We have certainly found that supporting monad,
> functor and applicative syntax has been useful – and that things like
> fold are general enough to allow you to build everything else
> regardless.
> 

I can see the value in adding a bind/map method but i don't see the value in turning Optional into fully fledged Stream-but-not-Stream-like thing. I think that would be taking the API in the wrong direction.

Paul.

 
> cheers,
> jed.
> 
> * https://bitbucket.org/atlassian/fugue/src/master/src/main/java/com/atlassian/fugue/Option.java
> 
> On 26 February 2013 21:37, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> Hi Jed,
>> 
>> An Optional.flatMap is somewhat different to Stream.flatMap(FlatMapper ). Should we also add filter, forEach and reduce methods to have some parity to that of Stream? that is what i am getting at when i used the expression "shoe-horn".
>> 
>> Stream.flatMap has been through a number of renames/redesigns and has very recently somewhat circled back on itself *and* we have added the following convenience method to Stream<T>:
>> 
>>    default <R> Stream<R> flatMap(Function<T, Stream<? extends R>> mapper) {
>>        return flatMap((T t, Consumer<R> sink) -> mapper.apply(t).sequential().forEach(sink));
>>    }
>> 
>> Since we are using the "flatMap" name it was felt important to have one method follow the pattern expected of it.
>> 
>> Hmm... maybe under such circumstances it is OK to add an Optional.flatMap ? Or alternatively choose a completely different name to disassociate from Stream e.g. like Guava's Optional.transform.
>> 
>> Paul.
>> 
>> On Feb 26, 2013, at 6:12 AM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
>> 
>>> Hi Paul,
>>> 
>>> You don't get a choice, it is a (or forms a) monad, you just removed
>>> the useful methods (map/flatMap aka fmap/bind). This leaves clients to
>>> implement them (or the functionality) in an ad-hoc and possibly buggy
>>> form themselves.
>>> 
>>> It is a monad if there exists some pair of functions:
>>> 
>>> A -> Option<A>
>>> Option<A> -> (A -> Option<B>) -> Option<B>
>>> 
>>> The first is Optional.of, the second is currently:
>>> 
>>> Optional<A> a = …
>>> Optional<B> b = …
>>> Function<A, Optional<B> f = …
>>> if (a.isPresent) {
>>> b = f.apply(a.get());
>>> } else {
>>> b = Optional.empty();
>>> }
>>> 
>>> rather than:
>>> 
>>> Optional<A> a = …
>>> Function<A, Optional<B> f = …
>>> final Optional<B> b = a.flatMap(f);
>>> 
>>> cheers,
>>> jed.
>>> 
>>> On 26 February 2013 00:12, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>> Hi Dhananjay,
>>>> 
>>>> It is not missing it was removed.
>>>> 
>>>> java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad.
>>>> 
>>>> Paul.
>>>> 
>>>> On Feb 23, 2013, at 12:27 AM, Dhananjay Nene <dhananjay.nene at gmail.com> wrote:
>>>> 
>>>>> It seemed to be there on the Optional class in b61 but is missing now. Is
>>>>> there some way to run map/flatMap operations on an Optional?
>>>>> 
>>>>> Thanks
>>>>> Dhananjay
>>>>> 
>>>> 
>>>> 
>> 
>>