Loose ends: Optional

[Remi Forax]

On 06/04/2013 04:57 PM, Tim Peierls wrote:
> On Mon, Jun 3, 2013 at 10:54 PM, Joe Bowbeer <joe.bowbeer at gmail.com 
> <mailto: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.

Did you consider that there is perhaps a better mechanism that give you 
the safety you want without the overhead you describe ?

> 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.

yes, if Optional is only used at the ends of a Stream.

>
>     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).

Yes, that's my conclusion too, Optional without fromNullable is useless 
for representing something that can be null.

>
> 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.

Again there are ways to force Optional to be used only as a return type 
and not in middle of angle brackets.

>
>     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.

Why ?

>
> --tim

Ok, there is a problem in the way Java uses null, this leads to a lot of 
NPEs, especially in rookie's code.
Before saying that Optional will save our world, we have already 
followed this kind of path, when we have decided
that there was a lot of ClassCastException and introduces generics. 
Given that we end up with half-baked generics
(reification is not the sole issue), I really think that we should take 
the time to explore, if it's a real issue or not,
what are scenarios we want to solve and how to solve it.

So instead to trying to commit ourselves to pattern like 
Optional/Option/Maybe which is basically a kind of boxing,
something we are now trying hard to remove (at least from the VM 
perspective),
I think it worth to explore the different alternatives.

Given we have no time to do that for 8, I think we should keep a simple 
Optional and
not commit ourselves to a specific pattern that tries to solve the NPE 
problem in Java using Optional.

Rémi