Encounter order

Andrey Breslav andrey.breslav at jetbrains.com
Thu Oct 25 13:32:23 PDT 2012


> void forEach(Block<? super T> block);
>
> This is only about side effects, so encounter order shouldn't enter 
> into the calculation.  Elements are fed to the block in whatever order 
> and thread they are available.
But do we guarantee the ordering of effects for sequential 
implementation? Just curious about what would the JavaDoc say for this 
method.

> Given this, my recommendation is:
>  - Have all the problematic (sort, uniqueElements, groupBy, reduceBy) 
> ops respect encounter order even though it may be expensive
>  - Provide an .unordered() op for people to opt out of the encounter 
> order when they know they don't care.
>  - Impute encounter order if we need one and there isn't one (rather 
> than throwing)
Overall, looks good to me.

Maybe groupBy and reduceBy aren't worth the trouble: at least if 
something returns a Map, IMO nobody expects ordering in this map. 
Collections in groupBy are a different story: this is very much like 
stable sorting.


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