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
