Where has the map method on Optional moved?
tim at peierls.net
Tue Feb 26 04:37:19 PST 2013
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.)
> 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
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.
More information about the lambda-libs-spec-observers