Eamonn McManus wrote:
David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only
method
> that provides true utility in this case.
I agree with that, and would just suggest to the person specifying the
method
to add a @see String#valueOf(Object)
David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only method
> that provides true utility in this case.
I agree with that, and would just suggest to the person specifying the method
to add a @see String#valueOf(Object). I find that the behavio
Am 09.10.2009 01:53, David Holmes - Sun Microsystems schrieb:
So to me: String toString(Object o, String useIfNull) is the only
method that provides true utility in this case.
I can follow this argumentation.
+1
-Ulf
Joe,
Joseph D. Darcy said the following on 10/09/09 04:30:
System.out.println("" + referenceOfAnyType);
will print "null" if referenceOfAnyType is null.
This is what the platform has done since the beginning.
Yes because String concatenation can not tolerate null values appearing,
so it is
Joe,
I understand your point, and that's why I countered with my String and
StringBuilder points. Those two classes are used underneath the covers
for inline concatenation, but, again, java.util.Objects has grander
intentions than string concatenation. This class is for all objects,
and however St
ors are useful.
Jason
> Date: Thu, 8 Oct 2009 10:51:50 -0700
> From: joe.da...@sun.com
> Subject: Re: Objects.toString [Re: What methods should go into a
> java.util.Objects class in JDK 7?]
> To: jason_mehr...@hotmail.com
> CC: core-libs-dev@openjdk.java.net
> I'm
Paul Benedict wrote:
Why would you choose to return "null" for any null object?
Because that is how the platform has always treated null in string
concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since yo
>> Why would you choose to return "null" for any null object?
>
> Because that is how the platform has always treated null in string
> concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since you are now
defining a global
Paul Benedict wrote:
Joe,
I'm preparing the first round of java.util.Objects with the
single-argument static toString method return "null" for null for final
review.
Why would you choose to return "null" for any null object?
Because that is how the platform has always treated null
Joe,
> I'm preparing the first round of java.util.Objects with the
> single-argument static toString method return "null" for null for final
> review.
Why would you choose to return "null" for any null object? Everyone
who has opined did disagree with replicating String.valueOf()
behavior. I don'
27;t see what connection there
is between Jigsaw and j.u.Objects.
-Joe
Jason
> Date: Thu, 8 Oct 2009 11:47:49 +0100
> Subject: Objects.toString [Re: What methods should go into a
java.util.Objects class in JDK 7?]
> From: scolebou...@joda.org
> To: core-libs-dev@openjdk.java
: What methods should go into a
> java.util.Objects class in JDK 7?]
> From: scolebou...@joda.org
> To: core-libs-dev@openjdk.java.net
>
> A number of us are proposing that Objects.toString(obj) should return
> "" when the object is null. I'm strongly in favour of t
+1 for me.
+1 also for having the overloaded version that can accept a fallback string.
Paul
+1 or drop Objects.toString(obj) completely.
-Ulf
Am 08.10.2009 12:47, Stephen Colebourne schrieb:
A number of us are proposing that Objects.toString(obj) should return
"" when the object is null. I'm strongly in favour of this, and it
removes any discussion of duplicated API (as it does somet
A number of us are proposing that Objects.toString(obj) should return
"" when the object is null. I'm strongly in favour of this, and it
removes any discussion of duplicated API (as it does something
different and more useful).
In favour/against +1/-1 ?
Stephen
2009/10/7 Joseph D. Darcy :
> Davi
15 matches
Mail list logo
