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

Joe Bowbeer joe.bowbeer at gmail.com
Fri Mar 15 03:26:19 PDT 2013


Doug,

I think your point that Optional and non-Optional forms of reduce are
already provided is significant.

I noticed that your proposed versions of findFirst and findAny have a
Predicate argument, but the Optional forms do not:

T findFirst(Predicate<? super T> predicate, T ifNone);

Why is this?



On Thu, Mar 14, 2013 at 4:36 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 03/14/13 13:06, Brian Goetz 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.
>>
>
> 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<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
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130315/65e3b904/attachment.html 


More information about the lambda-libs-spec-experts mailing list