RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8

[Jim Gish]

I'm just now reading "State of the Lambda" and beginning to get a handle 
on this discussion, which makes sense to me today (and didn't yesterday 
morning).  (All this stuff about "reduce" is definitely taking me back 
to my APL days.  "s <- ./list"  -- a concat/reduce operation (sans the 
delimiter of course))  Once I come up to speed more thoroughly I'll take 
a shot at this with join.  Your comments are definitely giving me food 
for thought.  Thanks,  JIm

On 05/03/2012 04:38 AM, Paul Sandoz wrote:
> On May 2, 2012, at 8:39 AM, Stuart Marks wrote:
>>
>> It's fun to think about how joining would work in a lambda/streamy 
>> kind of world, e.g.
>>
>>    stream.infix(",").join(new StringBuilder()).toString()
>>
>
> Indeed :-) [Paul ducks as he makes up stuff!]:
>
>   String s = stream.interpose(",").reduce(new ToStringReducer());
>
> since join can be considered a reduce operation, and the above could 
> be equivalent to:
>
>   String s 
> = stream.interleave(repeat(",")).drop(1).reduce(new ToStringReducer()); [*]
>
> As well as:
>
>   String s = stream.join(",") // can be optimal implementation 
> specific to strings, String.join could defer to this
>
>
>> or some such. There are a bunch of issues to consider here though, 
>> such as special-casing of types in the input stream, e.g., append 
>> CharSequence directly instead of calling toString(), treat int value 
>> as a Unicode code point, etc. There are also issues about the result 
>> type: StringBuilder? String? Appendable?
>>
>> As much as I like the lambda stuff, though, I don't think having 
>> stream-based joining will supplant the need to have a good old-fashioned
>>
>>    String.join(",", ...bunch of strings...)
>>
>
> Yes.
>
> Paul.
>
> [*] interleave could support one or more streams
>