hg: lambda/lambda/jdk: 3 new changesets

[Jim Gish]

On 05/30/2012 07:41 PM, Rémi Forax wrote:
> 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() ?
As I'm working on this, I think we may ultimately get there.  As I work 
through this it seems to be evolving in that direction, but we're 
proceeding slowly.  Let's see how it shakes out.

(I certainly like the splitAsStream <--> join relationship w.r.t. Iterable)

Cheers,
    Jim
> 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
>>>
>>>
>>>
>