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
discussed.
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)
Paul
On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain <jeffh...@rocketmail.com
<mailto:jeffh...@rocketmail.com>> wrote:
Hello.
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"
looking
weird to me).
Though, verbs in passive form in methods names might look strange to
a lot of people.
Regards,
Jeff.
