(original) (raw)
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) 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 <mr@sun.com>
> Date: Fri, 23 Oct 2009 10:10:35 +0200
> From: R�mi Forax <forax@univ-mlv.fr>
\> Le 23/10/2009 03:53, Joe Darcy a �crit :
>> Following up on this, what is the exact revised proposal?I agree. �The join methods should be instance methods, not static methods.
\>>
\>> 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.
\- Mark