RFR: 8005051: default methods for Iterator

[Paul Sandoz]

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

> On 12/14/2012 03:47 PM, Paul Sandoz wrote:
>> 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;
>>         }
> 
> I think you don't need to use an iterator for that,

That code above is a core piece of sequential stream functionality leveraged by *non-short circuiting* terminal ops, so those ops don't have to work out whether to push or pull the pipeline depending if there is an intermediate short-circuiting op (such as limit).

Paul.