RFR: 8005051: default methods for Iterator

[Remi Forax]

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, by example if you 
want to implement findFirst() all you need is to have a method 
findFirst() in every node that returns the first node found.

>
> Paul.
>

Rémi