Where has the map method on Optional moved?

[Paul Sandoz]

On Feb 26, 2013, at 1:37 PM, Tim Peierls <tim at peierls.net> wrote:

> On Tue, Feb 26, 2013 at 5:47 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Feb 26, 2013, at 6:16 AM, Sam Pullara <sam at sampullara.com> wrote:
> > I've never been comfortable with this. I'm glad Jed is calling it out.
> > Can we make Optional first class or remove it?
> 
> Trawling through the email archives i cannot find specific discussion on Optional.map/flatMap, anyone recall such discussion? There is some general discussion on not going down the route of an option monad.
> 
> In particular, you wrote:
> java.util.Optional has a narrower scope that optional things in other languages. We are not trying to shoe-horn in an option monad. 
> 
> And I say amen to that. Keep Optional, and keep it lean and mean. (At least as lean as the Guava Optional.)
> 

I notice Guava's Optional has a transform method:

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Optional.html#transform(com.google.common.base.Function)


>  
> Since we have added a Stream.flatMap method following the pattern expected of it, does that give more weight to argument of adding such a method to Optional, perhaps of the same or a different name to disassociate with Stream itself?
> 
> No, it doesn't. The two are unrelated. Stream is a lofty abstraction and Optional is (or should be) a grunt-level utility.
> 
>  
> I find myself more and more leaning towards the position of if we include an Option class some developers will expect bind functionality, it seems useful, and nor is it hard to explain its use while avoiding mention the "m" word.
> 
> The more you saddle Optional with "might be useful" and "X might want this" features, the harder it will be for regular people -- people who don't know what a monad is -- to assimilate and use Optional sensibly. One of the reasons Doug Lea is not an Optional fan is fear of things like Collection<Optional<T>>, something that is less likely to happen with a minimalist Optional.
> 

Especially so if we make it more difficult by removing the hashcode and equals methods.


> Here's another reason to stay lean: The more limited Optional is, the easier it will be some day to optimize away the extra object. Make it a first class participant and you can kiss those optimizations goodbye. 
> 

Very true.

Paul.