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) {
thro
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 "nonN
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 wrote:
> Hello.
>
> As Ulf said, I think "requireNonNull" could be the name of a me
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 conversat
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 a
On Tue, Jan 25, 2011 at 6:33 PM, Brian Goetz 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 discussed; th
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: bf1b937076db
Author:alanb
Date: 2011-01-26 18:01 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf1b937076db
7012663: javadoc warning in javax.swing.JComponent and
javax.swing.plaf.synth.SynthTextPaneUI
Reviewed-by: alexp
! src/share/classes/javax/swing/JComponen
Changeset: df371fd16386
Author:jjg
Date: 2011-01-26 11:20 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/df371fd16386
6554097: "final" confuses @SuppressWarnings
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/s
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
! test/java/nio/channels/FileChannel/Truncat
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
! src/share/classes/com/sun/to
I like the name *nonNull*. All other things being equal, shorter is better.
I've used the name *nonNull* for a few years, and it's feels right. To my
mind, *requireNonNull* does a worse job of suggesting that the method
returns its argument.
Josh
On Wed, Jan 26, 2011 at 8:40 AM, Brian Goetz
On Wed, Jan 26, 2011 at 3:44 PM, Joshua Bloch wrote:
> I like the name *nonNull*. All other things being equal, shorter is
> better. I've used the name *nonNull* for a few years, and it's feels
> right. To my mind, *requireNonNull* does a worse job of suggesting that
> the method returns its ar
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
> current
15 matches
Mail list logo
