Yes, to my aesthetics the static call
join(" ", "A", "call", "to");
is more sensible looking than
" ".join("A", "call", "to");
Especially when a call like
" ".join("Foo")
will not have " " in the returned String. However, the platform would
certainly be improved with any version of String.join compared to not
having it.
-Joe
Joe Kearney wrote:
Hi,
From the peanut gallery, it seems to me that there is a genuine reason
to leave join as a static method (if we're not going after the
google-collections approach of a Joiner class
<http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Joiner.html#on%28java.lang.String%29>)
in that split acts on one existing String, whereas join creates one
from others. On which object would you call the join method? The
separator? I know this was covered on this list before, but it still
strikes me as looking a little wierd.
",".join("a", "b", "c")
versus
Joiner.on(",").join("a", "b", "c")
Thanks,
Joe
2009/10/23 Mark Reinhold <m...@sun.com <mailto:m...@sun.com>>
> Date: Fri, 23 Oct 2009 10:10:35 +0200
> From: Rémi Forax <fo...@univ-mlv.fr <mailto:fo...@univ-mlv.fr>>
> Le 23/10/2009 03:53, Joe Darcy a écrit :
>> Following up on this, what is the exact revised proposal?
>>
>> In java.lang.String:
>>
>> public static String join(String separator, Iterable<?>
objects);
>> public static String join(String separator, Object[] objects);
>> public static String join(String separator, Object first,
Object... rest);
>>
>> with analogous methods in StringBuffer and StringBuilder return
that type,
>> respectively, instead of String?
>
> I don't know. In my opinion, the main problem with join
specified using
> static methods is that split is not currently specified as a static
> method. Because join is the dual of split, one could find the
usage of
> static methods weird.
I agree. The join methods should be instance methods, not static
methods.
- Mark
