Am 26.01.2011 00:33, schrieb Brian Goetz:
Since postconditions are labeled ensures in the r/e/m triad, this
method should be named ensureNonNull.
Right, there's precedent for ensureXxx methods to actually change the state of things to ensure
the postcondition, such as ensureCapacity()
Am 26.01.2011 13:31, schrieb Ulf Zibis:
The funtionality is:
Check the argument for non-nullity AND return it if the condition holds, otherwise fail by
throwing NPE.
IIRC, Object.nonNull(x) was introduced to preserve the developer from
repetitively coding:
if (x == null) {
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
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 wrote:
Hello.
As Ulf said, I think requireNonNull could be
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
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
On Tue, Jan 25, 2011 at 6:33 PM, Brian Goetz brian.go...@oracle.com wrote:
Additional notes: After much discussion on core-libs-dev, the name
requireNonNull() seemed the least objectionable.
I think requireNonNull(x) is confusing.
Remember there's two versions of someModifierNonNull being
The only reason we're even having this discussion now -- as we're well
past freeze for 7 -- is to prevent the current situation from getting
carved into stone, where we have a nonNull() precondition-enforcing
method in Objects. While the correct name for the
postcondition-producing version is
Changeset: abab55565eda
Author:darcy
Date: 2011-01-26 12:32 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abab55565eda
7013420: Project Coin: remove general expression support from
try-with-resources statement
Reviewed-by: alanb
!
Changeset: 3da26790ccb7
Author:jjg
Date: 2011-01-26 13:45 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3da26790ccb7
7013272: Automatically generate info about how compiler resource keys are used
Reviewed-by: mcimadamore
! make/build.xml
!
Executive summary: requireNonNull is the preferred name.
Date: Tue, 25 Jan 2011 18:33:47 -0500
From: brian.go...@oracle.com
mark.reinh...@oracle.com wrote:
I think requireNonNull(x) is confusing.
Remember there's two versions of someModifierNonNull being discussed; the one
currently in
11 matches
Mail list logo
