Re: [CLI] Javadoc
Hi Claude,
I just did after seeing your message, instead of going round and round ;)
Gary
On 2024/10/19 10:22:28 Claude Warren wrote:
> Gary,
>
> I went looking for the javadoc in question but did not find it. Did you
> already clean it up? If so, thanks. If not can you point to the issue?
>
> Thank you,
> Claude
>
> On Thu, Oct 17, 2024 at 3:08 PM Gary D. Gregory wrote:
>
> > Note that the Javadoc for org.apache.commons.cli.help.HelpFormatter use
> > deprecated code. Please update it or I can do it later.
> >
> > Gary
> >
> > On 2024/10/17 13:39:53 Claude Warren wrote:
> > > I think that all of the HelpAppendable methods expect that if null or
> > empty
> > > string is passed then nothing is output. In addition, for the list case
> > an
> > > empty list results in no output.
> > >
> > > I will update the documentation.
> > >
> > > On Thu, Oct 17, 2024 at 10:20 AM Arnout Engelen
> > wrote:
> > >
> > > > On Mon, Oct 14, 2024 at 9:29 PM Gary D. Gregory
> > > > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > We now have append methods like:
> > > > >
> > > > > public interface HelpAppendable extends Appendable {
> > > > >
> > > > > /**
> > > > > * Appends a header.
> > > > > *
> > > > > * @param level the level of the header. This is equivalent to
> > the
> > > > "1", "2", or "3" in the HTML "h1", "h2", "h3" tags.
> > > > > * @param text the text for the header
> > > > > * @throws IOException on write failure
> > > > > */
> > > > > void appendHeader(int level, CharSequence text) throws
> > IOException;
> > > > >
> > > > > ...
> > > > >
> > > > > The supertype defines behavior for null input, but here we do not, we
> > > > should either document it as:
> > > > > - Same as the super type, same kind of Javadoc
> > > > > - Explicitly document that it is up to the implementing class
> > > > >
> > > > > Thoughts?
> > > >
> > > > While for the general 'append' I can see the motivation for outputting
> > > > 'null' for null input. For headers it seems simply invalid to me, and
> > > > IMO it'd make more sense to declare all implementations should throw a
> > > > NullPointerException in that case.
> > > >
> > > > If we do decide to allow null here, I think we should define the
> > > > behavior in a way that all implementations can follow - which the
> > > > super type does nicely ('If csq is null, then characters will be
> > > > appended as if csq contained the four characters "null".'). I don't
> > > > see a strong reason to leave it up to the implementing class - what
> > > > would be the use case?
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > --
> > > > Arnout Engelen
> > > > ASF Security Response
> > > > Apache Pekko PMC member, ASF Member
> > > > NixOS Committer
> > > > Independent Open Source consultant
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> > >
> > > --
> > > 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
> >
> >
>
> --
> 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
Re: [DISCUSSs] new Iterator
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 that extends Iterator 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. Gary > > > > > Static methods (all methods return an ExtendedIterator) > > > >- createNoRemove(final Iterator 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 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) > > >- create(final Iterator 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> woundIterator) -- creates an > >Iterator 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 removeNext() -- extracts the next item from the iterator and calls > >remove() to remove it. > >- andThen(final Iterator other)-- uses an IteratorChain > >to create a chain of iterators. > >- filter(final Predicate predicate) -- uses a FilterIterator to > >exclude the items from the iterator. > >- ExtendedIterator map(final Function function) -- uses a > >TransformerIterator to transform the items to a new type. > >- > 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 iter; > > List 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
Re: [DISCUSSs] new Iterator
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 that extends Iterator 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. > > Static methods (all methods return an ExtendedIterator) > >- createNoRemove(final Iterator 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 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) >- create(final Iterator 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> woundIterator) -- creates an >Iterator 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 removeNext() -- extracts the next item from the iterator and calls >remove() to remove it. >- andThen(final Iterator other)-- uses an IteratorChain >to create a chain of iterators. >- filter(final Predicate predicate) -- uses a FilterIterator to >exclude the items from the iterator. >- ExtendedIterator map(final Function function) -- uses a >TransformerIterator to transform the items to a new type. >- > 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 iter; > List 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
Re: [DISCUSSs] new Iterator
What is the advantage of using an ExtendedIterator to filter/chain/map/flatten instead of using Stream to do the same? On Sat, Oct 19, 2024 at 5:16 AM 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 that extends Iterator and has the > following additional methods. > > Static methods (all methods return an ExtendedIterator) > >- createNoRemove(final Iterator it) -- prohibits removal on an >iterator that otherwise would allow removal. >- ofStream(final Stream stream) -- convenience method to create >ExtendedIterator from stream. >- create(final Iterator 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> woundIterator) -- creates an >Iterator by iterating through each of the iterators in > "woundIterator" > > Instance methods (Unless otherwise noted all methods return an > ExtendedIterator) > >- T removeNext() -- extracts the next item from the iterator and calls >remove() to remove it. >- andThen(final Iterator other)-- uses an IteratorChain >to create a chain of iterators. >- filter(final Predicate predicate) -- uses a FilterIterator to >exclude the items from the iterator. >- ExtendedIterator map(final Function function) -- uses a >TransformerIterator to transform the items to a new type. >- > 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 iter; > List lst = > ExtendedIteratot.create(iter).filter(Thing::isValid).map(thing -> new > OtherThing(thing)).addTo(new ArrayList<>()); > > Claude > -- > LinkedIn: http://www.linkedin.com/in/claudewarren >
Re: [DISCUSSs] new Iterator
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 that extends Iterator 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. Gary > > Gary > > > > > > > > > Static methods (all methods return an ExtendedIterator) > > > > > >- createNoRemove(final Iterator 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 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) > > > > >- create(final Iterator 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> woundIterator) -- creates an > > >Iterator 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 removeNext() -- extracts the next item from the iterator and calls > > >remove() to remove it. > > >- andThen(final Iterator other)-- uses an > > > IteratorChain > > >to create a chain of iterators. > > >- filter(final Predicate predicate) -- uses a FilterIterator to > > >exclude the items from the iterator. > > >- ExtendedIterator map(final Function function) -- uses a > > >TransformerIterator to transform the items to a new type. > > >- > 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 iter; > > > List 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
Re: [DISCUSSs] new Iterator
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 that extends Iterator 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) > > > > > > > >- createNoRemove(final Iterator 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 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) > > > > > > >- create(final Iterator 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> woundIterator) -- creates an > > > >Iterator 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 removeNext() -- extracts the next item from the iterator and > > > > calls > > > >remove() to remove it. > > > >- andThen(final Iterator other)-- uses an > > > > IteratorChain > > > >to create a chain of iterators. > > > >- filter(final Predicate predicate) -- uses a FilterIterator to > > > >exclude the items from the iterator. > > > >- ExtendedIterator map(final Function function) -- uses a > > > >TransformerIterator to transform the items to a new type. > > > >- > 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 iter; > > > > List 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 additiona
[DISCUSSs] new Iterator
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 that extends Iterator and has the following additional methods. Static methods (all methods return an ExtendedIterator) - createNoRemove(final Iterator it) -- prohibits removal on an iterator that otherwise would allow removal. - ofStream(final Stream stream) -- convenience method to create ExtendedIterator from stream. - create(final Iterator 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> woundIterator) -- creates an Iterator by iterating through each of the iterators in "woundIterator" Instance methods (Unless otherwise noted all methods return an ExtendedIterator) - T removeNext() -- extracts the next item from the iterator and calls remove() to remove it. - andThen(final Iterator other)-- uses an IteratorChain to create a chain of iterators. - filter(final Predicate predicate) -- uses a FilterIterator to exclude the items from the iterator. - ExtendedIterator map(final Function function) -- uses a TransformerIterator to transform the items to a new type. - > 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 iter; List lst = ExtendedIteratot.create(iter).filter(Thing::isValid).map(thing -> new OtherThing(thing)).addTo(new ArrayList<>()); Claude -- LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [CLI] Javadoc
Gary,
I went looking for the javadoc in question but did not find it. Did you
already clean it up? If so, thanks. If not can you point to the issue?
Thank you,
Claude
On Thu, Oct 17, 2024 at 3:08 PM Gary D. Gregory wrote:
> Note that the Javadoc for org.apache.commons.cli.help.HelpFormatter use
> deprecated code. Please update it or I can do it later.
>
> Gary
>
> On 2024/10/17 13:39:53 Claude Warren wrote:
> > I think that all of the HelpAppendable methods expect that if null or
> empty
> > string is passed then nothing is output. In addition, for the list case
> an
> > empty list results in no output.
> >
> > I will update the documentation.
> >
> > On Thu, Oct 17, 2024 at 10:20 AM Arnout Engelen
> wrote:
> >
> > > On Mon, Oct 14, 2024 at 9:29 PM Gary D. Gregory
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > We now have append methods like:
> > > >
> > > > public interface HelpAppendable extends Appendable {
> > > >
> > > > /**
> > > > * Appends a header.
> > > > *
> > > > * @param level the level of the header. This is equivalent to
> the
> > > "1", "2", or "3" in the HTML "h1", "h2", "h3" tags.
> > > > * @param text the text for the header
> > > > * @throws IOException on write failure
> > > > */
> > > > void appendHeader(int level, CharSequence text) throws
> IOException;
> > > >
> > > > ...
> > > >
> > > > The supertype defines behavior for null input, but here we do not, we
> > > should either document it as:
> > > > - Same as the super type, same kind of Javadoc
> > > > - Explicitly document that it is up to the implementing class
> > > >
> > > > Thoughts?
> > >
> > > While for the general 'append' I can see the motivation for outputting
> > > 'null' for null input. For headers it seems simply invalid to me, and
> > > IMO it'd make more sense to declare all implementations should throw a
> > > NullPointerException in that case.
> > >
> > > If we do decide to allow null here, I think we should define the
> > > behavior in a way that all implementations can follow - which the
> > > super type does nicely ('If csq is null, then characters will be
> > > appended as if csq contained the four characters "null".'). I don't
> > > see a strong reason to leave it up to the implementing class - what
> > > would be the use case?
> > >
> > >
> > > Kind regards,
> > >
> > > --
> > > Arnout Engelen
> > > ASF Security Response
> > > Apache Pekko PMC member, ASF Member
> > > NixOS Committer
> > > Independent Open Source consultant
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> > --
> > 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
>
>
--
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [DISCUSSs] new Iterator
@mdrob The reason to use an Iterator is that, from my experience, Stream requires all the base objects to be in existence. In addition there are times when you don't know how many objects there will be or that you have an iterator or iterable to start with and not a stream. An example would be reading from something like an S3 bucket where you make a call to get a list of object summaries. The list of object summaries may not be complete and so you have to make more calls to the API to get more and more object summaries. This is very easy to wrap with an iterator that will allow you to get all the object summaries and then you can do stream-like processing on the object summaries to process all the files in the S3 bucket. @Gary Gregory I have an implementation of this class in the a pull request for Rat 0.17. It is effectively a wrapper on some of the other iterator classes in commons-collections. With your example of how to do the unwinding/flattening iterator I can now rewrite it so that it does not need any other new classes in commons-collections. I am open to renaming methods as appropriate. I will put together a pull request on Sunday that shows how to implement the methods and will make method name changes as per your recommendations above. Claude
