Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)
pbenedict at apache.org
Wed Jan 26 16:00:24 UTC 2011
My implementation of asNonNull() is as follows: return (o != null) ? o :
That is a conversion that can succeed.
However, the conversation clearly has shown we need this (1) a null-safe
conversion method and (2) and a NPE-throwing check method. I was only
referring to the #1 and that's why I think "as" works here. For the latter,
I prefer "check" or "validate" to throw NPE when null is an error.
On Wed, Jan 26, 2011 at 9:48 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> This ground has been already covered. "as", "to", etc, are fine for
> conversions -- but by definition this is a conversion will never succeed.
> At the same time, we need to leave room in the namespace for a conversion
> operation that *will* succeed. (If we didn't need both, this whole
> conversation would be moot!) as/to/make are all fine for the
> "carpet-sweeping" version of this method, but that's not what's being
> On 1/26/2011 10:44 AM, Paul Benedict wrote:
>> Alternatively, we could use the "as" prefix already established in the
>> JDK -- since this function is a kind of conversion.
>> asNonNull(Object o, Object fallbackObj)
>> On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain <jeffhain at rocketmail.com
>> <mailto:jeffhain at rocketmail.com>> wrote:
>> As Ulf said, I think "requireNonNull" could be the name of a method
>> that just
>> checks that the specified reference is not null, and would not
>> return anything
>> (even though we could rather use "checkNonNull" in that case, and
>> make it
>> return true if non null).
>> Though, "notNullChecked" or "nonNullChecked" might seem to suppose
>> that the non-nullity of the specified value has already being checked.
>> A more appropriate name would be "checkNonNullAndReturnIt", but it's
>> too verbose.
>> I'm considering "beingNonNull" as an alternative, for
>> "beingNonNull(x)" contains
>> the idea that it is still "x", i.e. that it normally returns "x",
>> and that it supposes "x"
>> to be non null, i.e. that it checks it.
>> Also, the passive form "being" contains the idea that we don't
>> change anything to
>> the value.
>> An alternative to this alternative would be "notBeingNull", which
>> would be more on
>> pair with methods like "beingPrime"/"notBeingPrime" ("beingNonPrime"
>> weird to me).
>> Though, verbs in passive form in methods names might look strange to
>> a lot of people.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev