hg: lambda/lambda/jdk: 3 new changesets

[Brian Goetz]

Note also that StringJoiner will be used in the implementation of the 
upcoming (long-requested!) String.join methods, and can be used to 
implement various toString implementations more easily.



On 5/30/2012 7:26 PM, Rémi Forax wrote:
> On 05/31/2012 12:11 AM, Brian Goetz wrote:
>>> I don't like the class StringJoiner because despite the fact it's a
>>> reduce operation,
>>> it's implemented as a Fillable, so something eager which will not work
>>> as is in the parallel world.
>>
>> That's where we started -- trying to treat string joining as a reduce.
>> But because String is immutable, doing a sequential reduce with string
>> concatenation becomes an O(n^2) operation, which is not good.
>>
>> (Originally we thought that the way to do joining was:
>> stream.interleaveWith(Streams.repeating(", "))
>> .reduce(String::concatenate)
>> but the reduce step, which, while pretty, was inefficient.)
>
> join is a kind reduce operation that can be easily be implemented as a
> foldLeft
> on a StringBuilder.
>
> collection.foldLeft(new StringBuilder(),
> (element, builder) -> {
> if (builder.length == 0)
> return builder.append(element);
> return builder.append(", ").append(element);
> }).toString()
>
> for the parallel case, the question is how to implement foldLeft ?
> perhaps foldLeft should return an Iterable of StringBuilder() that you can
> reduce sequentially afterward.
>
>>
>> The parallel case isn't much better. Even if you do a number of string
>> joins at the leaves of the tree, the top-level combine still has to
>> copy all the string content, which loses most of the parallelism.
>>
>> But you can still do upstream ops in parallel:
>>
>> collection.parallel()
>> .filter(...)
>> .map(...)
>> .sorted()
>> .sequential()
>> .into(new StringJoiner(", "));
>>
>> and all the upstream stuff will happen in parallel.
>>
>>> I think it's better to add join() on Iterable.
>>
>> Would like to, but we can't add methods that only apply to specific
>> parameterizations.
>
> you don't have to because all objects have a method toString()
> or said in another way StringBuilder.append() takes an Object as parameter.
>
> cheers,
> Rémi
>
>
>