Loose ends: Optional

[Remi Forax]

On 05/24/2013 10:15 PM, Brian Goetz 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".

I think you cross a line without seen it, filter, map and flatmap are 
lazy on Stream but not on Optional.

Rémi

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