Streams -- philosophy

[Remi Forax]

On 12/31/2012 05:18 PM, Brian Goetz wrote:
> 6. Have a path to an open system.  Anyone can create a parallel Stream 
> by creating a Spliterator for their data structure (or, by providing 
> an Iterator, and letting us split that, albeit less efficiently.)  
> That's a good start.
>
> The Stream API is designed around an extensible set of intermediate 
> and terminal operations, which uses an "SPI" to define IntermediateOp, 
> StatefulOp, and TerminalOp.  While we do not plan to expose this SPI 
> in 8 (purely a triage decision; its not ready to stamp into concrete), 
> we want to expose it as soon as practical.  The internal 
> pipeline(XxxOp) methods would be exposed, and users who create new ops 
> could integrate them into existing pipelines like:
>
>   list.stream()
>       .filter(...)
>       .pipeline(dropEverySecondElement())
>       .map(...)
>       ...
>
> The "pipeline" method is the escape hatch to add new stages into the 
> pipeline (this is actually how all ops are implemented internally 
> now.)  Users would then be free to create new intermediate or terminal 
> operations and thread them into pipelines with pipeline(op). 

On that, I think Stream should not have the method iterator() and 
splitterator() public,
but Streams should have two static methods to expose an Iterator and a 
Spliterator.
just to not shut down the idea to find a better abstraction between the 
release of 9.

Rémi