On Oct 30, 2015, at 12:07 PM, Roger Riggs <[email protected]> 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.
