Loose ends: Optional

[Sam Pullara]

On May 28, 2013, at 10:12 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> On 05/28/2013 06:19 PM, Brian Goetz wrote:
>> 
>> As to your concern, I see it slightly differently.  It is not that the filter method is lazy on Stream and eager on Optional.  It is that *Stream* itself is laziness-seeking (all methods that do not require an immediate result defer what computation they can) and Optional itself is eager (all methods produce a fully formed result or side-effect).
> 
> Ok, filter is not filter in an object world, it's Stream.filter or Optional.filter,
> but in that case, why there is no eager implementation of filter on List, it's convenient too ?

Manipulating an Optional with if/then statements basically makes it no better than null. For that reason alone we should have these methods and possibly a few more like exists(). I still struggle with the fact that with the current API I still have to make my own object to Optional converter to handle nulls in what I think is a sane way. 

> Having methods like filter or map defined on Optional with a different semantics as the ones of Stream
> will just introduce doubt and confusion, so it doesn't worth it.

The implementation decides if something can be lazy, I'm ok with these having the same methods. In fact, I suggest we change the name of isPresent to forEach.

Sam

> 
> Rémi
> 
>> 
>>> On lambda-dev: 05/28/2013 05:35 PM, brian.goetz at oracle.com wrote:
>>>> Changeset: fde3666e6394
>>>> Author:    briangoetz
>>>> Date:      2013-05-28 11:34 -0400
>>>> URL:http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fde3666e6394
>>>> 
>>>> Additional convenience methods on Optional
>>>> 
>>>> ! src/share/classes/java/util/Optional.java
>>>> 
>>>> 
>>> 
>>> It seems, I have not received one or several emails about adding an
>>> eager versions of filter, map to Optional.
>>> The last email I received about that subject is the one below.
>>> 
>>> Rémi
>>> 
>>> 
>>> On 05/25/2013 07:12 PM, Remi Forax wrote:
>>>> 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
>>>> 
>>> 
>