Loose ends: Optional
forax at univ-mlv.fr
Tue Jun 4 15:28:30 PDT 2013
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
> 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
> 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
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.
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
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
not commit ourselves to a specific pattern that tries to solve the NPE
problem in Java using Optional.
More information about the lambda-libs-spec-observers