Optional -> OptionalResult

[Jed Wesley-Smith]

It bears repeating that Option is not a solution to null, and is not
peddled as such. It is a solution to optionality, for which null is often
used (see Map::get for instance). This has explained before, see for
instance:

http://mail.openjdk.java.net/pipermail/lambda-dev/2012-September/006050.html

As to List<Optional<T>> and the like, you never see this kind of thing in
actual code, apart from the input to something like
Iterables.concat(Iterable<Iterable<T>>)* which produces an Iterable<T>.
Indeed, this is essentially the motivation for and use case of the
bind/flatMap method on monads – to not end up with nested boxes. Optional
now has this very useful method Optional<T>::flatMap(Function<T,
Optional<U>>) -> Optional<U>. No nesting!

I don't think Java is actually a mutable language. If it was, you'd be able
to add your ? operator.

cheers,
jed.

* BTW this is one of the motivations for wanting Optional to implement
Iterable.

On 5 June 2013 19:20, Stephen Colebourne <scolebourne at joda.org> wrote:

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