RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong
dl at cs.oswego.edu
Thu Mar 14 16:36:04 PDT 2013
On 03/14/13 13:06, Brian Goetz wrote:
> I've closed the survey, results are at:
> 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
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?
(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:
>> where people can express their preference between:
>> - Leave things as they are (Optional-bearing methods for findXxx and
>> - 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!
More information about the lambda-libs-spec-experts