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.r...@oracle.com> > À: "Roger Riggs" <roger.ri...@oracle.com> > Cc: core-libs-dev@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.ri...@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.