Added PrefetchIterator

[t-novak]

Useful for construct like:

Dataset<T> data = Join.of(input, config)...;
ReduceByKey.of(data)
  .reduceBy((Stream<T> values, Collector<X> collector) -> {
    final PrefetchIterator<T> iterator = new PrefetchIterator<>(values);
    T first = iterator.prefetch();
    if (first != null) {
      if (first.selected())
        processSelected(iterator, collector);
      else
        processUnselected(iterator, collector);
    }
  });

[je-ik]

Just a minor concern about naming the prefetch method. Otherwise 👍 and we can merge this then.

[je-ik]

Can be name this peek? That is compliant with naming conventions of other methods performing this task.

[t-novak]

I'm in doubt about peek().

It has different meaning in java 8 stream API and maybe someone would like to add PeekingStream later doing the same thing on stream.

[je-ik]

I'd say, that the naming of Stream#peek seems unfortunate, but OK. Can we come up with some other naming that would be clear to users? I have a strong feeling that the current naming is not self-explanatory.

[t-novak]

OK, more names:

• LookupIterator::lookup()
• PeekingIterator::peek()
• PeepIterator::peep()
• SurveyIterator::survey()
• InspectIterator::inspect()
• ?

[je-ik]

I still vote for peek, but maybe others might have some opinion on this.

[dmvk]

I'd also say that peek is most self explanatory method and people are used to it. Stream::peak method seems really unfortunate. I've just found out that Peeking iterator is already part of apache commons https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/iterators/PeekingIterator.html and guava https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/PeekingIterator.html

Shouldn't we use the one that guava provides?

[je-ik]

@dmvk Cool, I wasn't aware of that. I think Iterators.peekingIterator(values.iterator()) does exactly this and we shouldn't reinvent the wheel. Also, as discussed over slack, motivation for this is probably missing #131
We should probably close this.