Loose ends: Optional

[Tim Peierls]

On Mon, Jun 3, 2013 at 10:54 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Without the extra methods, the Java8 Optional is similar to Guava's.
>  Fugue's Option is a more Scala-like replacement.  There are a few succinct
> arguments in favor of the extra methods, such as those posted by Jed
> Wesley-Smith (Fugue) and Ben Hutchison (
> http://benhutchison.wordpress.com/2012/06/05/a-rant-on-jdroids-and-wilful-ignorance/).
>  I would love to hear the Guava designers respond to Ben's charge of
> willful ignorance(!).  I'm also wondering if the new methods added in more
> recent versions of Guava are addressing these deficiencies.
>

The arguments in favor of the extra methods boil down to "Guava Optional
looks a lot like something I see/use in Scala/Haskell/FP code/literature
all the time, minus some methods. Therefore Guava Optional is deficient and
Java 8 Optional should restore those methods."

But Guava Optional is not trying to be any of the things its detractors
want it to be. (I find Ben Hutchison's arrogant accusation of ignorance
particularly galling.) It is only an alternative -- a better alternative --
to the practice of using null to signify a missing value, especially a
missing return value. Without it, users of an interface with methods that
can return null to signify "no value" can -- and do, repeatedly -- forget
to check for nullity and find out about their mistake only at runtime, if
ever. With it, users are forced to at least acknowledge the need to check
for a missing value. It can streamline the common cases of supplying a
default value or, with Java 8 lambdas, an exception to throw when the value
is missing.

Detractors of a different stripe don't want Optional at all because it
imposes overhead (in the code and at runtime) for what they think of as a
dubious virtue. "It's an extra layer of safety code that I don't need. Why
should I pay for the fallibility of others?"  That's a reasonable concern
in the abstract, but if Optional is primarily used at the end of stream-y
computations that might or might not return a value, the already tiny
overhead in practice is going to be dominated by the stream machinery.



> But, alas, I haven't had enough experience with Guava's Optional to form
> an opinion and I've had no experience with Fugue.  I have had experience
> with Scala's Option and it seems to work pretty well, but we decided
> earlier to opt for a more limited approach.
>

I have no practical experience of Scala Option or Fugue; I've only looked
at documentation. I use Guava Optional both as a client of Guava methods
and when defining my own APIs. It has saved my bacon many times and made my
code more readable. When working with legacy APIs that still use null to
represent missing values, I use things like Optional.fromNullable (to go
from legacy to my code) and Optional.orNull() (to go from my code to legacy
code).

I try to use Optional purely as a return type, and I try to avoid using
monstrosities like List<Optional<Foo>> (or worse) in an API. I confess that
in my first flush of excitement at having Optional, I went way overboard
and did, in fact, create some truly horrible method signatures, but the
crime conveys its own punishment, and I quickly learned what not to do.



> For at least one of the few use cases cited in favor of the extra methods,
> the Elvis operator produces the most readable results...  Is Elvis an
> Option?
>

I expect not.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130604/ca9d2760/attachment.html