Optional -> OptionalResult

[Stephen Colebourne]

On 5 June 2013 01:06, Jed Wesley-Smith <jed at wesleysmith.io> wrote:
> Map<Option<List<Foo>>> is clearly a straw-man. It does not make any sense to
> have a Map that has an optional key, nor does it make any sense to have an
> optional result, map already is a partial function! Regardless, "large"
> generic types are not by themselves scary – indeed, they are very useful. We
> already have the ability to hide complex product types at the value level,
> we just need a way to alias them at the type level.

Here is what Tim Pierls wrote:
On 4 June 2013 15:57, Tim Peierls <tim at peierls.net> wrote:
> 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.

While Tim clearly learnt the mistake, the reality is that APIs were
produced with poor method signatures. Developers will over-use
Optional, at least in part because the Scala community pushes it as
the solution to null, which it isn't.

The consistent rejection of adding the most basic language tools for
null (?. and ?:) is another factor (never mind null in the type
system). Developers know that null is a right royal pain and a problem
they'd love to solve. Since they are forbiidden useful language level
solutions, some will see Optional<T> as the new nirvana and thus
over-use it. To call it a straw man is to misunderstand why better
null-handling in Java was repeatedly voted by developers as the
language change they want.

> Option is not merely useful as a result type. It is useful anywhere you wish
> to indicate that a value is optional. For instance, in an input form in a
> GUI there may be non-mandatory input fields, or there may be inputs to a
> method that are not necessary for the caller to supply. You may consider
> overloading in the second case, but for a form structure this can prove
> unwieldy.

No, I'd just use null for something that is optional. It what Java has
used for donkeys years, what works with the JavaBean spec and doesn't
require extra thinking. What it does require is documenting whether
the parameter/return value can be null or not, but that should be done
anyway.

The key point is that Java (and Scala) still have null. Null cannot be
removed or eliminated. Any variable declared as type Optional<String>
can still be set to null. Optional is a false promise, making you feel
good, but not actually removing the danger of null.

> JodaTime fought the battle to
> bring immutability to a date API and is clearly superior to the previous
> library for being so. Immutability is a corner-stone of what makes FP – the
> ability to program with values. There is no need to believe there is a
> disconnect, or that you are somehow on the "other side" from functional
> programmers. We are all on the same side, trying to make better libraries
> and applications that are easier to reason about, easier to write and easier
> to maintain.

Java is a mutable language, far from the ideals of FP. Joda-Time and
JSR-310 provide an immutable low-level library, which has real and
tangible benefits. But trying to expand that immutability beyond
low-level libraries given (a) the language facilities available in
Java, and (b) the history of Java, is at best painful.

Stephen