RFR 9: 8138963 : java.lang.Objects new method to default to non-null
john.r.rose at oracle.com
Sat Oct 31 20:06:37 UTC 2015
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:
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.)
On Oct 31, 2015, at 12:51 PM, Vitaly Davidovich <vitalyd at 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 <forax at 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.rose at 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.
More information about the core-libs-dev