Loose ends: Optional

[Brian Goetz]

Boy, it seems that one can't discuss Optional in any context without it generating hundreds of messages.  

Whatever we do here is a compromise between several poles whose proponents hold very strong opinions.  There are those that really want Elvis instead; there are others who feel that a box-like class for Optional is a hack when it really should be part of the type system.  Neither group is going to get what they want here; we can compromise and make everyone a little unhappy, or we can do nothing and make everyone unhappy (except that they will still hold out vain hope for their pet feature in the future.)  

This is made worse by the fact that many of those that have advocated for a Fugue-like interpretation of Optional (like Ben Huchinson) have behaved atrociously (which sadly is all too common among the neo-functional crowd).  It is very hard to listen to someone whose approach is offensive and unreasonable and hear any of the merit in their argument.  (Also, the first seven times this came around, it was simply the wrong time to discuss it -- there were much bigger fish to fry, and choices made for Optional might have constrained the design space of higher-priority features, so it made sense to say "not now.")  

Sadly I am not optimistic that new and compelling observations will result from continued debate (though I would have liked for Kevin to share his opinions on-list.)  At a meta-level, I'll observe that: 

 - Those that have argued for these methods do so on the basis of having used them elsewhere and found them useful;
 - Those who have argued against them do not appear to have used them in anger, instead offering mostly FUD-like arguments such as possibility for user confusion or misuse or cost.  

So I have to give more credibility to the supporters than the detractors.  There are lots of people who want this for reasons grounded in actual experience, and I'm inclined to let them have what they want (even if some of them asked extremely rudely.)  

I'm willing to hold this topic open for a few more days, to hear from those who have NOT already expressed a strong opinion.  

 
On Jun 4, 2013, at 3:28 PM, Remi Forax wrote:

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