A summary of the reasoning behind Optional's API?

[Graham Allan]

Hey all,

First of all, just let me say, I am not wishing to bring up a
discussion about the upcoming Optional's API, or to suggest changes. I
have read the discussion here[1] and don't want to cover old ground.

What I am asking for, is if it would be possible to summarise and
publicise the arguments put forward on Google's internal Java mailing
list which lead to the planned API for Optional. I obviously don't
want the entire source posted online, just a couple of general bullet
points would do.

The reason I ask is that our team is attempting to use an Optional-
like construct (adopting Nat Pryce's Maybe[2]) and are finding
ourselves frequently banging into problems. Things like not having a
standard Function0 to map the 'orElse' value to, not having a side-
effect only function type to lazily execute against None. There are
ways to get around these examples, but we've not found any of them to
be particularly satisfying, and are wondering if it's the language,
the implementation, or just us :-)

It would be really useful if we could find out the reasons behind
Optional's API, to see if they align with the kind of problems that a
more functional, Scala Option-like construct leads to in Java.

Thanks for a great library,
Graham


[1] http://groups.google.com/group/guava-discuss/browse_thread/thread/2558185aae955387
[2] https://github.com/npryce/maybe-java

[Kevin Bourrillion]

It would be a thousand times easier to just discuss specific issues, such as:

On Tue, Sep 6, 2011 at 11:04 AM, Graham Allan <grundl...@googlemail.com> wrote:

Things like not having a
standard Function0 to map the 'orElse' value to,

What does this mean?  It sounds like Optional.or(Supplier) to me.

 

not having a side-
effect only function type to lazily execute against None.

Again I'm not clear on what this means.  Optional.sendTo(Receiver)?  (Not necessarily good names.)

 

There are
ways to get around these examples, but we've not found any of them to
be particularly satisfying, and are wondering if it's the language,
the implementation, or just us  :-)

One of the biggest misconceptions out there about Guava is that we are actually trying to make functional programming in Java awesome.  We have no such delusions, and aren't FP kool-aid-drinkers.  We have just added certain things as we have needed them.  But FP-like programming in Java will only become palatable in JDK 8, and when that day comes the JDK will have all these types like Procedure or Block or whatever itself, so you won't be needing Guava to supply them then either.

-- 

Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com

[Tim Peierls]

On Tue, Sep 6, 2011 at 2:16 PM, Kevin Bourrillion <kev...@google.com> wrote:

One of the biggest misconceptions out there about Guava is that we are actually trying to make functional programming in Java awesome.  

Leave off the "functional", though, and ... mission accomplished! Or so say all of me.

--tim

[Graham Allan]

What does this mean?  It sounds like Optional.or(Supplier) to me.

Yes, this exists for Guava's Optional, but there's no ' public Optional<Other> or(Function<T, Other>)'[1] to act on the optional value. This is vice-versa for the Maybe implementation we're currently trying out. Since we're free to modify that implementation to suit our needs, it may just be case of adding the 'public T or(Supplier<T>)' signature to Maybe to get what we're after (since Supplier will be on the classpath anyway). I think we'd also be after something like public void 'doSideEffect(Supplier<Void>)' (yeah, I can hear the FP-purists cringe :-) )

Another aspect in Scala's Option, or Maybe is that the .get() is discouraged or not even available, where Guava's Optional has no such qualms. I think these kind of differences are just adding to my confusion with "deprecating null" in general.

Again I'm not clear on what this means.  Optional.sendTo(Receiver)?  (Not necessarily good names.)

Yes, that's along the lines of what I mean, could also be described as 'public void sendTo(Function<T, Void>)', which like I say, can be done, but it seems pretty clunky. 

But FP-like programming in Java will only become palatable in JDK 8 <snip>

 I think that's the cold hard fact we're facing, and we should either accept the language we're in, or move on from it, instead of trying to shoehorn Java into something more FP-like when it doesn't have the constructs available. Is it fair to say that's perhaps why Optional is missing the likes of filter(), fold(), map() and flatMap()?

Thank for the quick feedback, and for the record, I agree with Tim :-)

Kind regards,

Graham

[1] Which I think me be called map or transform in other languages.

[Kevin Bourrillion]

On Tue, Sep 6, 2011 at 1:28 PM, Graham Allan <grundl...@googlemail.com> wrote:

Yes, this exists for Guava's Optional, but there's no ' public Optional<Other> or(Function<T, Other>)'[1] to act on the optional value.

And we haven't ruled that out, but we spent way too much time on this Optional stuff for the time being.

This is vice-versa for the Maybe implementation we're currently trying out. Since we're free to modify that implementation to suit our needs, it may just be case of adding the 'public T or(Supplier<T>)' signature to Maybe to get what we're after (since Supplier will be on the classpath anyway). I think we'd also be after something like public void 'doSideEffect(Supplier<Void>)' (yeah, I can hear the FP-purists cringe :-) )

Another aspect in Scala's Option, or Maybe is that the .get() is discouraged or not even available, where Guava's Optional has no such qualms. I think these kind of differences are just adding to my confusion with "deprecating null" in general.

Who's deprecating null, though?

Again I'm not clear on what this means.  Optional.sendTo(Receiver)?  (Not necessarily good names.)

Yes, that's along the lines of what I mean, could also be described as 'public void sendTo(Function<T, Void>)', which like I say, can be done, but it seems pretty clunky. 

But FP-like programming in Java will only become palatable in JDK 8 <snip>

I think that's the cold hard fact we're facing, and we should either accept the language we're in, or move on from it, instead of trying to shoehorn Java into something more FP-like when it doesn't have the constructs available. Is it fair to say that's perhaps why Optional is missing the likes of filter(), fold(), map() and flatMap()?

Well, that but mostly the fact that we just really need to work on other stuff.

It's important to realize that it was never our goal to create God's Gift To All Things Optional.  Just something, hopefully simple, that could serve in a few of the pinches our users were feeling (such as not being able to store null in a ConcurrentHashMap).