Loose ends: Optional

[Brian Goetz]

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.


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

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