Optional -> OptionalResult

[Stephen Colebourne]

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