On 2024/10/19 18:44:17 "Gary D. Gregory" wrote:
> On 2024/10/19 16:16:09 "Gary D. Gregory" wrote:
> >
> > On 2024/10/19 16:12:45 "Gary D. Gregory" wrote:
> > > Hi Claude,
> > >
> > > Interesting stuff :-)
> > >
> > > I'll assume that you intend this discussion for Commons Collections. Note
> > > that there are some stream/iterator mix utilities in Commons Lang in the
> > > org.apache.commons.lang3.stream.Streams class.
> > >
> > > A few comments below.
> > >
> > > On 2024/10/19 10:15:38 Claude Warren wrote:
> > > > I would like to introduce a new Iterator to the iterator library:
> > > > ExtendedIterator
> > > >
> > > > This Iterator is an Iterator that extends the functionality of other
> > > > iterators and makes using some iterators in the library more idiomatic.
> > > > It
> > > > is based on the ExtendedIterator found in the new Apache Rat core
> > > > package
> > > > that was inspired by the Apache Jena ExtendedIterator interface.
> > > >
> > > > I propose a class ExtendedIterator<T> that extends Iterator<T> and has
> > > > the
> > > > following additional methods.
> > >
> > > Assuming that other calls are delegated to the underlying Iterator, a
> > > name that matches the JDK that might be better is "FilterIterator", much
> > > like what a FilterInputStream does for an InputStream.
> >
> > Maybe there a plain FilterIterator like FilterInputStream and a
> > FilterIterator subclass that has the additional methods, not sure.
>
> Doh, we already have org.apache.commons.collections4.iterators.FilterIterator.
FilterIterator suports Predicates. I would assume that this new 'extended'
functionality would either extend FilterIterator or add new functionality to it.
Gary
>
> Gary
>
> >
> > Gary
> >
> > >
> > > >
> > > > Static methods (all methods return an ExtendedIterator<T>)
> > > >
> > > > - createNoRemove(final Iterator<T> it) -- prohibits removal on an
> > > > iterator that otherwise would allow removal.
> > >
> > > You'll need to specify what this means: Does the turn the call into a
> > > noop or provides the default Iterator implementation, throwing a
> > > UnsupportedOperationException
> > >
> > > > - ofStream(final Stream<T> stream) -- convenience method to create
> > > > ExtendedIterator from stream.
> > >
> > > I don't think the name should "double-up" the words "of" and "Stream".
> > > Either follow the JDKs, example of java.util.Arrays.stream(...) where the
> > > target type is the method name, so in this case "iterator", or since we
> > > know we're creating an Iterator, just "of", like
> > > java.util.stream.Stream.of(T...) and
> > > org.apache.commons.lang3.stream.Streams.of(Iterator<E>)
> > >
> > > > - create(final Iterator<T> it)-- creates an ExtendedIterator from a
> > > > plain iterator. If the Iterator is already "extended" just return
> > > > it.
> > > > - emptyIterator() -- convenience method to creat an empty
> > > > ExtendedIterator.
> > > > - unwind(final Iterator<Iterator<T>> woundIterator) -- creates an
> > > > Iterator<T> by iterating through each of the iterators in
> > > > "woundIterator"
> > >
> > > The wind/unwind terminology does not make sense to me. I think we should
> > > follow what the JDK does with Stream and call this operation "flat" or
> > > "flatten", following Stream.flatMap(Function) and other Stream "flat"
> > > methods.
> > >
> > > >
> > > > Instance methods (Unless otherwise noted all methods return an
> > > > ExtendedIterator<T>)
> > > >
> > > > - T removeNext() -- extracts the next item from the iterator and
> > > > calls
> > > > remove() to remove it.
> > > > - andThen(final Iterator<X> other)-- <X extends T> uses an
> > > > IteratorChain
> > > > to create a chain of iterators.
> > > > - filter(final Predicate<T> predicate) -- uses a FilterIterator to
> > > > exclude the items from the iterator.
> > > > - ExtendedIterator<U> map(final Function<T, U> function) -- uses a
> > > > TransformerIterator to transform the items to a new type.
> > > > - <U extends Collection<T>> U addTo(final U collection) -- Adds the
> > > > remaining items in the iterator to the collection.
> > > >
> > > > The advantage of the iterator is the idiomatic nature.
> > > >
> > > > Iterator<Thing> iter;
> > > > List<OtherThing> lst =
> > > > ExtendedIteratot.create(iter).filter(Thing::isValid).map(thing -> new
> > > > OtherThing(thing)).addTo(new ArrayList<>());
> > >
> > > Note that Streams use the "collect" name for this type of operation.
> > >
> > > I am somewhat concerned that this proposal is implementing what already
> > > in Streams but with Iterator. It might just be simpler to use Streams,
> > > _especially_ considering your last example, which is very stream-like.
> > >
> > > TY!
> > > Gary
> > >
> > > >
> > > > Claude
> > > > --
> > > > LinkedIn: http://www.linkedin.com/in/claudewarren
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
