Abstract LazyIterator.create() is called when the first hasNext or next
is called. Hence the expensive iterator is not made until first use.
Having
LazyIterator(Supplier<X>) supplier)
is a more modern style than subclassing.
Aside: our own "Creator<X>" interface has an explicit "new each call"
semantics, unlike strict Supplier<X>.
On 02/12/17 15:06, ajs6f wrote:
Claude-- have you looked at the Guava machinery underneath
Iterators.concat(...)? I _believe_ that it is fully lazy, although I haven't
looked at it in a while.
Yes, for concat(Iterator<? extends Iterator<? extends T>> inputs)
And pass in a LazyIterator for the others.
The same will work for IteratorConcat.
Andy
https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/Iterators.html#concat(java.util.Iterator)
https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/Iterators.html#concat(java.util.Iterator...)
etc.
ajs6f
On Dec 2, 2017, at 9:42 AM, Claude Warren <[email protected]> wrote:
I know that the IteratorIterator class was deprecated some time ago in
favor of WrappedIterator.createIteratorIterator(). However they have
different performance characteristics.
the original IteratorIterator, did not call iter.next() on the base
iterator until it was needed. createIteratorIterator() creates the
iterators using the (iter.next()).andThen( iter.next() ) type construct.
Basically calling next() on the base iterator to create an iterator over
the results.
The problem is that when the base iterator is returning expensive (or very
memory hungry) iterators they are all loaded before the final iterator is
ready for use.
I know that there is a lazy iterator but I don't see how to use that to
solve the problem.
I propose we bring back the IteratorIterator and describe when to use it.
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
