RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Samedi 9 Décembre 2017 00:48:08
> Objet: Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

>>>> Please review this changeset that introduces a new no-arg method
>>>> orElseThrow() to Optional, as a preferred alternative to the get()
>>>> method.
>>>>
>>> This looks good. The naming is consistent and I think better than the
>>> "getWhenPresent" proposed in the original thread.
>> 
>> i agree with Alan.
>> 
>> Having a name that starts with "get" as the great advantage as to be visible in
>> the IDE completion box just after the method get() so it will help people to
>> transition from get() to getWhenPresent()
> 
> I'm not sure whether you're agreeing or disagreeing. :-)

oops, read the Alan's reply too fast.

> 
> The current proposal is for orElseThrow().
> 
> Having a method that starts with "get" (such as "getWhenPresent" or
> "getOrThrow") is indeed helpful when doing auto-completion, but it sort-of
> starts to create a new family of get- methods that overlap with the existing
> orElse- methods in an odd way. I think the no-arg orElseThrow() fits better with
> the existing three orElse- methods. This leaves get() as the outlier, which is
> ok if we maybe eventually deprecate it.

ok, make sense.

> 
>> BTW, i do not see the point to not deprecate get() at the same time.
> 
> Much of the resistance to the earlier proposal was about deprecation of get(),
> so I wanted to set that aside in order to proceed with introduction of this
> alternative.

ok

> 
> s'marks

Rémi