Is Joiner.on("") readable enough?

[GoogleCodeExporter]

Some users are saying they find Joiner.on("") to be a less than ideal way to 
join strings with no separator.  They'd like an alternate static factory like 
Joiner.withNoSeparator() (name unknown, really).

I'm open to arguments for and against this.  My personal feeling is that 
nothing we do can be as obvious in its meaning as Joiner.on("") -- whatever 
method we come up with, users will have to go read it and understand it as some 
_new_ concept. I don't see a lot of value in that, but again, I'm listening.

Original issue reported on code.google.com by kevinb@google.com on 6 Sep 2012 at 5:19

[GoogleCodeExporter]

In my opinion, Joiner.on("") is just fine and easy to understand.

Original comment by cgdecker@google.com on 6 Sep 2012 at 5:34

[GoogleCodeExporter]

I think Joiner.join(...) for joining strings with no separator would be natural 
and clear.

Alternatively, a no argument factory method?  The advantage of which would be 
that you can pass it to something that expects a Joiner, and/or customize it 
with skipNulls, useForNulls, etc.

I lean towards the latter although I'm not sure it looks that great to say 
Joiner.on().join(...)  I'm not sure a different factory method name would 
improve the situation though.

Original comment by andrewba...@google.com on 6 Sep 2012 at 6:11

[GoogleCodeExporter]

I think Joiner.join(...) for joining strings with no separator would be

It would mean that, basically, all 15 instance methods of Joiner would have
to be repeated as static methods.  We took this approach for
MinMaxPriorityQueue and its Builder, but that was only four methods.

Original comment by kevinb@google.com on 6 Sep 2012 at 6:16

[GoogleCodeExporter]

Kevin, can you elaborate on the perceived problems with Joiner.on("")?

Call me thick, but I think it's extremely clear and certainly preferable to the 
alternatives proposed so far. Also, providing _another_ method for this 
functionality is in conflict with the principle that there should preferably be 
only one obvious way to perform simple operations. From "The Zen of Python":

    There should be one-- and preferably only one --obvious way to do it.

Original comment by stephan...@gmail.com on 6 Sep 2012 at 8:14

[GoogleCodeExporter]

I'll have to let the people who perceive the problems do the explaining.  Well, 
I'll paste what they said so far.

"I'm worried about the conceptual overhead of 'oh, I'm joining on a 
thing...wait, the thing is an empty string...so I'm actually joining on 
nothing...oh, so it's just appending the pieces.'"

"Treating 'joining strings together' as 'joining strings together with things 
in between where the things in between are empty strings' is not very natural 
to me at least."

Original comment by kevinb@google.com on 6 Sep 2012 at 8:20

[GoogleCodeExporter]

I can only speak for myself, but it's very natural to me... just like a loop 
which might be executed zero times.

Let's approach this from another angle: are there any other languages/APIs with 
a Joiner-like construct that treat this case specially? I'm not aware of any. 
(To reference Python once more: there ''.join(...) is a frequently-seen 
expression.)

Original comment by stephan...@gmail.com on 6 Sep 2012 at 8:26

[GoogleCodeExporter]

"Guava strives for a high power-to-weight ratio"

So if Joiner.on(whatEverStringEvenEmptyOne) fulfill 100% of the cases in a 
simple manner, why bother adding new method ? 

This is really "Much ado about nothing" (Shakespeare)

Original comment by amer...@gmail.com on 6 Sep 2012 at 9:19

[GoogleCodeExporter]

While I agree that it isn't a necessity, I prefer a method with obvious 
semantics to the technical version of passing in an empty String.

The first time I used Joiner.on("") I first checked the source to see whether 
Joiner actually accepted empty delimiters. Having a factory method like 
withEmptyDelimiter() would make this obvious and easier to understand.

Original comment by SeanPFl...@googlemail.com on 7 Sep 2012 at 10:45

[GoogleCodeExporter]

This seems like an easy optimisation to make, but it might be smarter to 
include it as a distinct method like Joiner.concat() rather than try to detect 
"". Not that detecting "" and taking action on that would be difficult or 
resource intensive somehow but rather that it would make the code for 
Joiner.on(String) look needlessly complicated. 

I don't have strong feelings either way though, just chiming in with some ideas.

Original comment by e...@google.com on 9 Sep 2012 at 4:22

[GoogleCodeExporter]

It would be nice if such a method's name would start with "on" (say, 
"onEmptySeparator") so that a connection between the two methods is easily seen.

Additionally, IDEs' auto-completion would suggest the clearer method when one 
is beginning with the original one.

Original comment by j...@nwsnet.de on 10 Sep 2012 at 7:42

[GoogleCodeExporter]

Not sure it's any better, but just to throw it out there - how about 
Joiner.on()?  But I'm in the "there's already a way to do it so why add a new 
one" camp, so whatever...

Original comment by s...@google.com on 13 Sep 2012 at 6:27

[GoogleCodeExporter]

Thanks everyone. After weighing all the feedback I'm ready to conclude, "if it 
ain't broke, don't fix it."  Joiner.on("") already works and it's behavior is 
very clear.

Original comment by kevinb@google.com on 13 Sep 2012 at 6:54

• Changed state: WontFix

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit