RFR 9: 8138963 : java.lang.Objects new method to default to non-null
vitalyd at gmail.com
Sat Oct 31 20:15:08 UTC 2015
It's hard to escape bikeshedding, everyone's subconsciously favorite
To me, checkNull still means there's an error path somewhere there (I've
seen plenty of internal validation/util APIs where check methods throw if
arg is null). To me, we're saying "here's a method that returns default if
arg is null", which is an if statement on null. So ifNull, ifNullThen,
defaultIfNull, etc seem to convey slightly more of the intent.
sent from my phone
On Oct 31, 2015 4:06 PM, "John Rose" <john.r.rose at oracle.com> wrote:
> OK, it's Halloween, so a certain amount of bikeshed vandalism might be
> I will to select my spray-paint color from the following paint-store aisle:
> http://www.thesaurus.com/browse/deter <
> There's something in there to charm everyone. Personally, I would fall
> > <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
> 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 <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