Loose ends: Optional

[Remi Forax]

On 05/28/2013 10:07 PM, Sam Pullara wrote:
> 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().

You mean null for signalling that there is no value I suppose.
It's better than null in that case because Optional force the developer 
to check if the value is present or not.

If you want to call any method on it (beside the one already existing), 
what you want in not 0ptional but null safe navigation
(the .? of groovy by example). This pattern is by far more powerful but 
it was rejected by the coin project, that the gordian knot of this issue.
So Optional is a pale replacement, I agree. But you can't add all the 
methods that exist on earth in it.

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

yes, Optional have not the same semantics as Optional (from Guava).

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

No, it's not the implementation that decides, it's the spec. You can not 
realistically change the implementation of a method from lazy to eager 
and vice versa. It's the argument of Brian, the spec of Optional will 
say that the method filter of Optional is not lazy. But relying on 
people reading the documentation is something that you should not do 
(hint people don't read the spec). Or should do for your most important 
concept of the API, not for something as minor as Optional. For 
Optional, it should just work, without thinking too much.

>
> Sam

Rémi

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