hg: lambda/lambda/jdk: 3 new changesets

[Rémi Forax]

On 05/31/2012 01:31 AM, Brian Goetz wrote:
> 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.

I know that this has been requested a long time ago because I've written 
a patch for that 2 or 3 years ago (at least).

But why String.join(separator, iterable) can't just call 
iterable.foldleft(...).toString() ?

Rémi

>
>
>
> 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
>>
>>
>>