RFR 9: 8138963 : java.lang.Objects new method to default to non-null

[Remi Forax]

Hi John,
I think there is a good reason to not reuse/enhance the requireNonNull prefix,
requireNonNull here is used to check a precondition or an invariant (a contract), hence a name that starts with 'require' like in Eiffel.
(BTW re-reading this thread, Brian already said that)

requireNonNullElseGet is not something that checks a contract and as you said, nonNull is not a good prefix too, so we should starts a new family.

what about:
  <T> T coalesceNull(T, T)
  <T> T coalesceNullGet(T, Supplier<? extends T>)

cheers,
Rémi

PS: COALESCE is already use as an operator in SQL with the same semantics.

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Roger Riggs" <roger.riggs at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Envoyé: Samedi 31 Octobre 2015 08:01:03
> Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to	non-null
> 
> On Oct 30, 2015, at 12:07 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
> > 
> > The longer names disambiguate adequately but add to the bulk of the code.
> > I see maturing systems end up being weighed down by the seemingly necessary
> > qualification.
> 
> I agree with your statement of the problem, but (personally) am less repulsed
> by long names.
> 
> The name length is unusual (up to "requireNonNullElseGet", if that's the new
> API spelling).  It would be inconvenient to write manually but (IMO) that
> isn't a deal-killer.  Coders cope with long names (check class name lengths
> in java.lang).  It's a matter of taste, and (particularly) of how much the
> coder relies on name-completion commands.
> 
> Given the pre-existing methods in the "nonNull" family and the
> "requireNonNull" family, it is tricky to fit in the new API points with
> either prefix.  The "nonNull" family is short and sweet, but was adopted
> (one might say "stolen") for use as a predicate (sans "is"-prefix).    The
> "requireNonNull" family was long-winded, even before we thought about adding
> "ElseGet".  (How did we settle on "require", anyway?)
> 
> > So in face of the tradeoffs, what were you proposing again?
> 
> 
> Despite the length of the names involved, I'm going to clutch at my IDE and
> my Control-Space key, maintaining my preference for the consistency of
> requireNonNull* over the brevity (but inconsistency) of notNull*.  As I
> said, I noticed the problem with "notNullElse" while using an IDE.  Non-IDE
> users would look at my preference and say, "please, not so many keystrokes!"
> In the IDE, I would prefer to pretend "notNull" never happened, and type
> "require" and Control-Space, and then select one of the old or new API
> points to refine my null-checking logic.
> 
> — John
> 
> P.S. Going for a third way and starting a new family of methods ("notNull*",
> "stopNull", etc.) would make me sad too, since we already have null-stopping
> API points.  I'd secretly welcome Objects.or(a, b, c), etc. (coupled with
> "require*" to throw NPEs), but only because "OR" is a sort of logical
> in-joke for ex-Lispers.