Simplifying sequential() / parallel()

[Joe Bowbeer]

Doug writes

>don't belong in any stream op not called forEach

I'm with you there.

Will we be able to advertise that one can easily rewrite any 'for' loop
using each()?

This is one of those useful talking points in the introductory articles:
See, these new features aren't completely alien. You can take any for loop
and transform it like so... If so, then forEach is an apt, intuitive name.
Otherwise, some distance is needed.

Joe
On Mar 22, 2013 11:57 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

On 03/22/13 10:07, Joe Bowbeer wrote:

> Stateful programming has its issues but that ship has already sailed (in
> Java).
>
>
Although it is worth bearing in mind that most stream functionality
wrt Collections exploits the fact that operations within
traversals are already known to avoid some of the worst unexpected
side-effects -- mutating a collection while you are traversing.
Which normally leads to ConcurrentModificationExceptio**n for
iterators. A variant of this is preserved when applicable
in Spliterator implementations. People learn quickly to avoid them.
(That's the subject of some of the specs Paul Sandoz has been
adding, which can't be nailed down very well in general because
they are quality-of-implementation issues, but he is trying anyway :-)

Anyway, as the chief advocate for cool mutative algorithmics
in this group, I'm still in favor of saying they don't belong
in any stream op not called forEach.

-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130322/6e40a36f/attachment.html