RFR: 8005051: default methods for Iterator

[Paul Sandoz]

On Dec 14, 2012, at 2:34 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 12/14/2012 02:00 PM, Paul Sandoz wrote:
>> On Dec 14, 2012, at 11:54 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> We can't remove Collection.forEach without having perf issue because the stream pipeline use it.
>>> Iterator.forEach can be removed but it's a pity because it's really convenient,
>> And a case can be made performance wise too (there are optimal implementations in the stream code base).
>> 
>> I have found that forEach, in general, has been very useful. Since it abstracts away the details of traversal it has enabled better re-use of code.
> 
> thinking a little bit more about what you said, for the sequential implementation of the pipeline, there is no reason to use Iterator.forEach,
> if you can use forEach, it means that the logic can be encapsulated in a forEach, so the terminal op is not a short-circuited operation,
> so you can write it without an iterator.
> 

It's used in the sequential case when the pipeline is short circuited:

        @Override
        public<S extends Sink<E_OUT>> S into(S sink) {
            Objects.requireNonNull(sink);

            if (isShortCircuit()) {
                sink.begin(getOutputSizeIfKnown());
                iterator().forEach(sink);
                sink.end();
            }  else {
                super.into(sink);
            }

            return sink;
        }

Paul.