Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)
brian.goetz at oracle.com
Wed Jan 26 15:48:12 UTC 2011
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.
More information about the core-libs-dev