Remove cumulate from Stream interface (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Wed Dec 5 15:11:37 PST 2012

I think I agree with Rémi.

Programmers should not have to think twice (and will not) about converting their for-loops into forEach forms.

However, they should think twice before adding "parallel()".

On Wed, Dec 5, 2012 at 3:05 PM, Remi Forax <forax at univ-mlv.fr> wrote:

On 12/05/2012 07:55 PM, Brian Goetz wrote:

Plus, your Mapper will violate the to-be-written specs about

statefulness/side-effects in lambdas passed to functional stream methods.

Do you really want this overly restrictive wording for streams that are sequential ? I find this unrealistic, even if you try to specify this in the doc, nobody read the doc if not forced. Given that will not be enforced in the code, it will be only true on the paper. It may be unrealistic, but we have to do it anyway. If someone passes a Function to map() that mutates the collection source, all bets are going to be off, and we have to say this. yes, but mutating the collection source is not the same as saying no side effect. Moreover, i have trouble to understand why the old rules can't be applied for serial stream. If the collection is a concurrent collection, there is no problem, . If the collection is not concurrent, it will fail-fast. For parallel stream, if the lambda have side effects, i agree that there is no guarantee. The spec can characterize when things are guaranteed to work; if people do things that accidentally work because they are operating in a restrictive environment, that's their concern. that why I think that sequential stream should always work or get a fail-fast exception and parallel stream should only work for lambda with no side effect. Rémi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121205/fec3bd67/attachment.html

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