Brian, My implementation of asNonNull() is as follows: return (o != null) ? o : fallbackObj.
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. Paul On Wed, Jan 26, 2011 at 9:48 AM, Brian Goetz <brian.go...@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 > 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. >> >> >>
