Into

[Joe Bowbeer]

I was going to say something about into() here but the topic has morphed to
sequential()?

Concerning into(),

I was just translating a simple example from Uncle Bob's recent FP
resolution(*).  The most difficult problem given the current state of
jkd8lambda was trying to print a stream...

Using StringJoiner seems like the coolest way to do this currently:

  stream.into(new StringJoiner(", ", "[", "]"))

But how's this supposed to work without into()?


Btw, the lack of a generic Joiner that accepts any ol' object or primitive
is causing me some grief.  Given a stream of ints or even Integers, having
to manually map(Object::toString) seems like something StringJoiner should
be doing automatically.

Joe

(*)
http://blog.8thlight.com/uncle-bob/2012/12/22/FPBE1-Whats-it-all-about.html


On Sun, Dec 23, 2012 at 7:33 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> It is sort of a variant of what I've been suggesting, though not quite
> going as far as serialForEach/parallelForEach.  In my view the modes that
> need to be explicitly chosen between are
>
>   reduce/functional/associative/**order-sensitive
> vs
>   forEach/mutative/commutative/**order-insensitive
>
> (This distinction only makes a difference in the parallel case, so it is
> slightly different from the forEach/forEachParallel distinction, but in a
> similar spirit of "less mind reading.")
>
>
>
> On 12/23/2012 9:35 AM, Doug Lea wrote:
>
>> On 12/23/12 07:02, Doug Lea wrote:
>>
>>>
>>>  Your asking people to take car about the concurrency in their code
>>>> instead of
>>>> letting the pipeline taking care of that.
>>>>
>>>
>>> Only for mutative updates, for which they will need to take
>>> the same care in any choice of seq vs par for any use of forEach.
>>> So there is nothing much special/interesting about this.
>>> The main idea is to be uniform about how mutative constructions
>>> are less fluent/streamy-looking than functional usages.
>>>
>>>
>> (To continue to re-open old wounds :-)
>> For extra Bondage&Discipline/friendly-**guidance, we could always
>> re-choose to separately support forEach and parallelForEach methods
>> and get rid of implicit moding for forEach.
>> Implicit moding can never hurt you in this sense
>> for the functional/stateless operations. There are still
>> several other stateful ones that would require some similar
>> separation though.
>>
>> Which might be a variant of what Brian was suggesting a few days ago?
>>
>>
>> -Doug
>>
>>