Optional -> OptionalResult

[Jed Wesley-Smith]

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.

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.

Elsewhere, you state "Those from an FP background will clearly see it as
something different (if related) and continue to be disappointed (Java
isn't going to satisfy them no matter what).". I would like to politely
disagree (having been doing exactly that for years now), and also to make
the claim that you are yourself a functional programmer. 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.

cheers,
jed.


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

> Optional is, and will continue to be, a key debating point for those
> arguing for more FP. The pressure to make it more powerful will
> continue, especially given similar named features in other languages.
>
> Meanwhile I continue to fear Map<Optional<List<Optional<String>>> and
> the like. The generics type system in Java simply isn't good enough to
> be doing anything like that, even if it were remotely desirable.
>
> Where the class is useful is in the return position. As Brian says "I
> think where we've tried to land is: do things that encourage people to
> use Optional only in return position".
>
> However, the one thing that hasn't been done is to name it as such.
> Simply rename "Optional" to "OptionalResult", or just "Result" and
> many of the issues go away. Those from an FP background will clearly
> see it as something different (if related) and continue to be
> disappointed (Java isn't going to satisfy them no matter what). More
> importantly, Java developers will only use the class in the return
> type position, simply because of its name.
>
> Of course it doesn't prevent Map<Result<List<Result<String>>>, but it
> makes it much less likely just because the name no longer makes sense.
> If it is used in that way, its probably because it really is a
> collection of earlier results.
>
> Finally, I'd note that if named Result/OptionalResult, I don't overly
> mind which set of methods are on it or that it is a box. So long as
> there is the ability to query it using a simple if statement.
>
> Stephen
>
>
>
> On 24 May 2013 21:15, Brian Goetz <brian.goetz at oracle.com> wrote:
> > Optional has obvious upsides and downsides.  Some of the downsides are:
> >  - It's a box.  Boxing can be heavy.
> >  - The more general-purpose value-wrapper classes you have, the more some
> > people fear an explosion of unreadable types like
> > Map<Optional<List<String>>, List<Optional<Map<String,
> > List<Optional<String>>> in API signatures.
> >
> > I think where we've tried to land is: do things that encourage people to
> use
> > Optional only in return position.  These methods make it more useful in
> > return position while not increasing the temptation to use it elsewhere
> any
> > more than we already have.  Hence "mostly harmless".
> >
> >
> > On 5/24/2013 4:10 PM, Tim Peierls wrote:
> >>
> >> On Fri, May 24, 2013 at 3:20 PM, Brian Goetz <brian.goetz at oracle.com
> >> <mailto:brian.goetz at oracle.com>> wrote:
> >>
> >>     Proposed spec for methods on Optional, which would have the obvious
> >>     counterparts in Optional{Int,Long,Double}.
> >>
> >>     These methods are known to be useful and seem mostly harmless now
> >>     that other things have settled.  (I don't think they greatly
> >>     increase the moral hazard of Optional in general, and they do make
> >>     it more expressive.)
> >>
> >>
> >> I'm in the curious (unique?) position of both desperately wanting
> >> Optional and desperately *not* wanting lots of additional methods like
> >> these. If the price of having Optional is the presence of these methods,
> >> I'll suck it up, but "mostly harmless" is not exactly a ringing
> >> endorsement.
> >>
> >> --tim
>
>