Into

[Brian Goetz]

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
>