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