Loose ends: Optional

[Remi Forax]

On 05/28/2013 06:19 PM, Brian Goetz wrote:
> No, you did not miss anything.  We have never required that an issue 
> be fully settled in the EG before committing it to the lambda 
> repository. Having code to play with often plays a critical role in EG 
> and community discussions, so we have regularly committed code to the 
> lambda repository that has not yet been fully blessed by the EG.
>

I thought it was before we start to sync lambda with jdk8 repo, sorry, 
my mistake.

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

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.

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