Jason Johnson wrote:
> Well, the interesting thing about this package is that it joins any 
> collection with any other collection, it's not just strings.

It's really just strings. You're getting confused by the (sorry to say 
that) poorly written code. It uses <SequenceableCollection> joinUsing: 
<delimiter> which looks very general at first glance but once you dig 
into it you'll notice that it really ought to be <delimiter> join: 
<Collection> and that really only String is a meaningful delimiter here. 
The implementation as it is creates a lot of clutter by doing it the 
other way around and then (needlessly) double-dispatching into Character 
and String. Besides which the code is very poorly formatted and not 
documented at all(there isn't even a single comment anywhere despite 
some highly unusual patterns). Not the kind of stuff I like to see in 
the kernel.

> Wanting code to be concise is code smell?  If you meant adding a method 
> to collections that only joins strings is a code smell then ok, but 
> otherwise.... well I strongly disagree to say the least.

Concise can mean different things. If it means a bloated collection 
interface to accommodate every single person's pet extensions then I 
think that stinks. And that's exactly what we've seen over the last 
years - ever-increasing amounts of partially overlapping functionality 
none of which is widely used and only makes it more difficult to find 
the few truly useful methods. Split for example, is for all practical 
purposes completely subsumed by findTokens: so why do we need split in 
addition to findTokens?

Cheers,
   - Andreas