Into (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Mon Dec 24 15:25:23 PST 2012

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121224/619295ab/attachment.html

More information about the lambda-libs-spec-experts mailing list