Thanks Viktor, I like your concept of multiple vantage points a lot.
Implementor: "use ofGreedy to signal that this operation does not itself initiate short-circuiting" Reviewer: "when you see ofGreedy verify that this operation does not itself initiate short-circuiting" Debugger: "when the expectation was that the stream should be short-circuiting and isn't, one thing to look for is ofGreedy" Implementor: "use ofSequential to signal that this operation is intended to always be executed sequentially" Reviewer: "when you see ofSequential, understand why the operation can't/shouldn't be parallelized for parallel streams" Debugger: "if the parallel stream is not performing as well as expected, one thing to look for is ofSequential!
I just don't see how these scenarios are parallel. To me, the following would be parallel. Scenario I: Brag about better performance As implementor, I can always go the easy route with of/of: sequential, non-greedy. It'll work, but performance may suffer. Or I can assert that I have done the extra care: ofParallel/ofGreedy. As reviewer, I see the deluxe ofParallel/ofGreedy, and I verify that the operation enables parallel execution/doesn't short circuit. As debugger, I see slow performance, and I am not surprised if it's the lame of/of. Scenario II: Warn of worse performance As implementor, I aim to produce the most performant way with of/of: parallelizable, greedy. Nice names for the good stuff. If I can't, I'll alert with ofSerial/ofShortCircuit. As reviewer, I see the coveted of/of, and I verify that the operation enables parallel execution/doesn't short circuit. As debugger, I see slow performance, and I am not surprised if it is ofSerial/ofShortCircuit. They had it coming. Either naming pair (ofParallel/ofGreedy or ofSerial/ofShortCircuit) feels consistent to me. But I find of/ofGreedy and ofSerial/of awkward to explain. Maybe just a mental block on my side. If other programmers worked with the API and found it consistent, don't mind me. I just thought to bring it up in case this has not received a lot of scrutiny. It is a pretty specialized aspect, after all. Cheers, Cay PS. I also think it would be helpful to be more explicit in the javadoc about the value of exploiting greediness. What is the sweet spot? Recognizing that nothing in the pipeline is short-circuiting and then pushing elements through without checking? Or more aggressive parallelization? I looked at the source code of Gatherer/Gatherers/GathererOp, and it is not obvious to me how one can see a significant performance win with greediness. Can you recommend a benchmark for me to study? -- Cay S. Horstmann | https://horstmann.com
