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

[Joe Bowbeer]

Three comments, by the block who opposed the additional mechanism,
expressed their view very clearly.  This view is that there should only be
one good way to do this, otherwise we have failed.  Doug's view, when he
expressed it before, was that we should add another way in case we are
wrong (and to satisfy those who prefer the other way).  If there is a "best
of both worlds" argument, I have yet to hear it.


On Thu, Mar 14, 2013 at 10:06 AM, Brian Goetz <brian.goetz at oracle.com>wrote:

> I've closed the survey, results are at:
>
>
> https://www.surveymonkey.com/**sr.aspx?sm=**c2NqWp6wXUxCUlr6SY05nYEyYIr7Sh
> **zH3IgL4OXPIYM_3d<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.
>
>
> 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<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
>>>
>>>