Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)
Paul Benedict
pbenedict at apache.org
Wed Jan 26 15:44:05 UTC 2011
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 <jeffhain at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110126/ba91f408/attachment.html>
More information about the core-libs-dev
mailing list