brian.goetz at oracle.com
Mon Oct 7 10:04:34 PDT 2013
I think a bit off-target, but I'm not sure it is too far? The history
here is that we used to support arbitrary transitions between seq-ness
We then realized that (a) this ability added lots of complexity and (b)
the only use case we could think of was "generate stuff in parallel and
forEach it sequentially." So we created forEachOrdered for that
purpose. (I think it might once have been called "forEachInOrder".)
So you are right that the intent of forEachOrdered did include some
sequentiality to it. So, question is, is the current naming and
proposed semantics reasonable?
On 10/7/2013 12:51 PM, Tim Peierls wrote:
> If so, doesn't the name "forEachOrdered" become a bit off-target? Doc
> readers are sure to confuse the ordered-ness of the stream with the
> "-Ordered" modifier in the method name. Something like
> "forEachSequentially" would be more on-target.
> On Mon, Oct 7, 2013 at 12:38 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
> Recall that Stream.forEach(action) may perform the action for
> different elements in whatever order, in whatever thread, with
> whatever concurrency it chooses, and forEachOrdered(action) promises
> to perform the action in encounter order.
> Working through the specs, I think users are expecting a
> tail-to-head sequencing of actions, and that processing element n
> <i>happens-before</i> processing element n+1?
> The real question is: what should happen when you do a
> .forEachOrdered() on an unordered stream. My first thought was that
> this was plain old forEach. But, I think this is not what the user
> will expect; I believe they will be reasonably expecting that the
> action is performed in some order, one element at a time.
> So I'm inclined to spec that this operates in *some* order, which is
> the encounter order if one exists, and that there is a HB edge
> between successive actions?
More information about the lambda-libs-spec-experts