RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong

[Doug Lea]

On 03/14/13 13:06, Brian Goetz wrote:
> I've closed the survey, results are at:
>
>
> https://www.surveymonkey.com/sr.aspx?sm=c2NqWp6wXUxCUlr6SY05nYEyYIr7ShzH3IgL4OXPIYM_3d
>
>
> Here, we did not reach a clear consensus.  However, I think some people may have
> misunderstood the question.  I'll let Doug, as proponent of this approach, take
> another swing at what is being proposed here, and why this might achieve
> best-of-both-worlds.

The argument is straightforward. Nothing very best-ish about it though:

1. It is possible to obtain all functionality of all Stream
methods without encountering Optional, except for findAny/findFirst.

2. Optional remains controversial. Some people hate it. Some
people love it. Why single out findAny/findFirst as a battleground?

-Doug

(PS: As always, I think Optional is so great as to be essential if you
have Value types. Oh, we don't have Value types...)

>
> On 3/10/2013 7:22 PM, Brian Goetz wrote:
>> I've posted a survey for the EG at:
>>
>>    https://www.surveymonkey.com/s/NSXMYC2
>>
>> where people can express their preference between:
>>   - Leave things as they are (Optional-bearing methods for findXxx and
>> reduce);
>>   - Add, as Doug suggests, non-optional versions of these too.
>>
>> Implementation / spec complexity is a non-issue here -- the
>> implementations are trivial.  The sole issue is whether the API is
>> better with one version or with both.
>>
>> The password has been communicated directly to the EG; contact me if you
>> didn't get it.
>>
>> Usual survey rules: enter your name with your response, all results will
>> be made public after the survey closes.  I'll set a closing time of 6PM
>> PT Wednesday of this week.
>>
>>
>> On 3/6/2013 7:09 AM, Doug Lea wrote:
>>> (Restricting to lambda-libs list...)
>>>
>>> On 03/06/13 04:47, Remi Forax wrote:
>>>> Ok, let be nuclear on this,
>>>> There is no good reason to introduce Optional<T> in java.util.
>>>
>>> We agree about most of the rationale for not using Optional.
>>> But there are still people who say they want it.
>>> I don't think it is productive at this point to
>>> argue about features supporting an Optional-laden
>>> programming style. But we never seem to hit closure
>>> about features supporting an Optional-free style.
>>> So I'd like to re-propose a simple compromise.
>>> In the same way that there are Optional and
>>> basis-returning versions of reduce:
>>>
>>>   T reduce(T identity, BinaryOperator<T> reducer);
>>>   Optional<T> reduce(BinaryOperator<T> reducer);
>>>
>>> (Where the basis-returning one can in turn be used to
>>> avoid Optional-returning min(), etc). We should do the
>>> same at least for find, or  more in keeping with current
>>> API, findFirst and findAny:
>>>
>>>   T findFirst(Predicate<? super T> predicate, T ifNone);
>>>   T findAny(Predicate<? super T> predicate, T ifNone);
>>>
>>> People wanting to avoid Optional can then then
>>> get all of the derived versions (allMatch, plain
>>> findAny, etc) easily enough.
>>>
>>> Surprisingly enough, that's the only missing
>>> feature that would otherwise enable a completely
>>> Optional-free usage style of the Stream API.
>>>
>>> We have both proposed variants of this several times,
>>> but they don't seem to go anywhere. It would be nice
>>> to have a calm final discussion about why we would NOT
>>> do such an apparently sensible thing!
>>>
>>> -Doug
>>>
>