Getting rid of pull

[Paul Sandoz]

On Dec 19, 2012, at 5:19 AM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> 
> If we got rid of support for iterator wrapping, we could still simulate an Iterator as follows:
> 
> - Construct a terminal sink which accumulates elements into a buffer (such as that used in flatMap)
> - Construct a push-oriented sink chain which flows into this buffer
> - Get an Iterator for the source
> - When more elements are needed, pull elements from the source, push them into the sink, and continue until out of elements or until something flows into the terminal buffering sink.  Then consume elements from the buffering sink until gone, and if there are more elements remaining in the source, continue until the pipeline is dry.  (Think of this as a "pushme-pullyou adapter.")
> 
> This has slightly higher overhead, but it seems pretty reasonable, and doesn't get used that often.  And then, all the code having to do with wrapping iterators can go away, and iterators are then only used as sources and escape hatches (and internally within short-circuit operations.)  Pretty nice.
> 

I have a working patch (no tests fail) that removes iterator wrapping the above. 

The result is very clean and greatly simplifies the operation implementations. 

The Stream.iterator() implementation becomes slightly more complicated but i think that is a reasonable cost to pay for the overall simplification and potential performance benefits.


> 
> We can even go one step farther, and eliminate iterators completely, but it involves some ugliness.  The ugliness involves use of an exception to signal from a forEach target through the forEach source to the initiator of the forEach to about dispensing of elements.  (We can eliminate most of the cost of the exception by not gathering the stack trace, which is by far the most expensive part.)  Then, Spliterator need not even support an iterator() method, just a forEach method that doesn't fall apart if you throw an exception through it.  (Similarly, we don't expose an iterator() method, just a version of forEach that lets the target say "no mas" which causes the exception to be thrown.)  This would eliminate even more low-value code (and simplify the Spliterator spec) that the above approach.  But the exception thing is kind of stinky.
> 
> 
> I don't see any reason to not do at least the first one.
> 

+1

Paul.