On Thu, Jan 27, 2011 at 2:20 AM, Bob Lee wrote:
> 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
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 place
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
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 w
> > About the name, I propose:
> > iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
>
> But there are two methods we want to rename this to, and we can't use
> this name twice. I propose we generate random method names instead.
You don't want to violate trademarks either.
How about 'vetoN
About the name, I propose:
iUsedToUseGetClassHereButNodobyWasAbleToUnderstand()
But there are two methods we want to rename this to, and we can't use
this name twice. I propose we generate random method names instead.
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()
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
On 27 January 2011 05:05, wrote:
> 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:
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
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
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
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
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
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
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
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
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
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
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(
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 r
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;
the one currently in Objects is the precondition-enforcing variety,
> Date: Tue, 25 Jan 2011 15:24:26 -0500
> From: brian.go...@oracle.com
> ...
>
> These methods should be renamed to something that makes its
> checking/verification behavior clear, while preserving the convenient
> self-return property so that it can be used in cases like:
>
> public void fooW
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 mis
The other good benefit from this rename is that "requireNonNull" is much
more expressive when used as a static import.
On Tue, Jan 25, 2011 at 2:24 PM, Brian Goetz wrote:
> There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly
> named) at:
>
>
> http://cr.openjdk.java.net
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 v
25 matches
Mail list logo
