Hi,
And, going back nearly to the beginning of the thread, some folks are
familiar with
T firstNonNull(T, T) proposed from Guava.
But since the exercise was turned into simplify: (x != null) ? x :
requireNonNull(y);
My favorite at this point is to identify the thread as a failed attempt
and remove it.
?: is going to be easier to type; and might even get some help from the IDE.
Roger
p.s. I occasionally work with an IDE but never exclusively when developing
across 4 OS's and sometime remotely. xemacs and vi are the most
portable and reliable.
On 10/31/15 2:06 PM, John Rose wrote:
OK, it's Halloween, so a certain amount of bikeshed vandalism might be
allowable.
I will to select my spray-paint color from the following paint-store aisle:
http://www.thesaurus.com/browse/deter <http://www.thesaurus.com/browse/deter>
There's something in there to charm everyone. Personally, I would fall for:
<T> T checkNull(T, T)
<T> TcheckNullElseGet(T, Supplier<? extends T>)
The trick is to remember that "check" can be a synonym for "deter" as in hockey.
The treat is that "checkNull" reminds every Java programmer of "null check".
Plus it's not taken yet.
(Gonna have to shower after this is over.)
— John
On Oct 31, 2015, at 12:51 PM, Vitaly Davidovich <vita...@gmail.com> wrote:
How about Objects.ifNull? Short and sweet. I don't like requireXXX for this
semantic either.
On Oct 31, 2015, at 4:17 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
what about:
<T> T coalesceNull(T, T)
<T> T coalesceNullGet(T, Supplier<? extends T>)
On Oct 31, 2015, at 12:01 AM, John Rose <john.r.r...@oracle.com> wrote:
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.
