On Thu, Jan 27, 2011 at 2:20 AM, Bob Lee crazy...@crazybob.org wrote:
On Wed, Jan 26, 2011 at 3:44 PM, Joshua Bloch j...@google.com 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,
Am 28.01.2011 05:58, schrieb David Holmes:
Rémi Forax said the following on 01/27/11 18:43:
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place
On 01/27/2011 10:58 PM, David Holmes wrote:
Rémi Forax said the following on 01/27/11 18:43:
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
On 27 January 2011 05:05, mark.reinh...@oracle.com wrote:
Executive summary: requireNonNull is the preferred name.
Date: Tue, 25 Jan 2011 18:33:47 -0500
From: brian.go...@oracle.com
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place in the JDK.
About the name, I propose:
iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
Rémi Forax said the following on 01/27/11 18:43:
On 01/27/2011 09:38 AM, Stephen Colebourne wrote:
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
I think we can't.
This method is already used at many place in the JDK.
I think we can. Those usages
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
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
There is a webrev for CR 7012540 (java.util.Objects.nonNull()
incorrectly named) at:
http://cr.openjdk.java.net/~briangoetz/7012540/webrev/
Code review would be appreciated.
Text of CR:
The class java.util.Objects is new for JDK 7. Its mission is to provide
null-safe or null-tolerant
Looks good; approved,
-Joe
Brian Goetz wrote:
There is a webrev for CR 7012540 (java.util.Objects.nonNull()
incorrectly named) at:
http://cr.openjdk.java.net/~briangoetz/7012540/webrev/
Code review would be appreciated.
Text of CR:
The class java.util.Objects is new for JDK 7. Its
requireNonNull() seems to be the best compromise.
The changes look good to me.
Mike
On Jan 25 2011, at 12:24 , Brian Goetz wrote:
There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly
named) at:
http://cr.openjdk.java.net/~briangoetz/7012540/webrev/
Code review
18 matches
Mail list logo
