[
https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated COLLECTIONS-213:
--------------------------------------
Attachment: COLLECTIONS-213.patch
Attaching Dusan's changes as a patch as it's hard to work with old copies.
> CollectionUtils API extension: algorithm methods accept an Iterator argument
> ----------------------------------------------------------------------------
>
> Key: COLLECTIONS-213
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-213
> Project: Commons Collections
> Issue Type: Improvement
> Components: Core
> Reporter: Dusan Chromy
> Fix For: 3.3
>
> Attachments: COLLECTIONS-213.patch, CollectionUtils.java,
> TestCollectionUtils.java
>
>
> I just finished the Iterator additions to CollectionUtils, including test
> cases and I am going to
> attach them to this issue very shortly (basically as soon as I figure out how
> attaching in JIRA works :)
> At first I was thinking for a while whether CollectionUtils is a good place
> to accomodate the methods with the
> new signature, until I noticed the collect method already accepts an Iterator
> argument.
> Following methods now accept an Iterator argument (besides collect):
> cardinality
> find
> forAllDo
> countMatches
> exists
> I also noticed cardinality used to throw a NPE if the collection argument was
> null.
> I see no reason why it should not return zero. The Iterator flavour does
> return zero
> and I also modified the Collection version to return zero (including Javadoc
> modification) for the sake of consistence.
> I stopped to think for a while before touching the method, but the fact
> that the Javadoc does not mention "may not be null" made me think the NPE is
> not thrown
> intentionally. And after all, cardinality(..) is nothing else than
> specialized countMatches(..),
> which returns 0 for null collection. However, feel free to reject the change
> to the cardinality(Object,Collection)
> method if you think otherwise.
> I worked on a fresh checkout from subversion and I just updated few minutes
> ago to make sure I have modified
> the latest version. Anyway, please double-check before commiting the changes.
> Cheers,
> Dusan
> > I think that these methods would make useful additions to the API.
> >
> > I don't have the time to do much collections work these days, but if you
> > want to code the methods with test cases and attach them to JIRA then that
> > would be great.
> >
> > Stephen
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > I've been using some algorithm methods from the CollectionUtils, for
> > > example
> > > find(Collection, Predicate)
> > > exists(Collection, Predicate)
> > > countMatches(Collection, Predicate)
> > > forAllDo(Collection, Closure)
> > >
> > > However, I would also like to be able to use these algorithms with an
> > > Iterator:
> > >
> > > find(Iterator, Predicate)
> > > exists(Iterator, Predicate)
> > > countMatches(Iterator, Predicate)
> > > forAllDo(Iterator, Closure)
> > >
> > > The obvious workaround is to use IteratorUtils.toList(Iterator), however
> > > this comes at the cost of constructing a list object (an ArrayList
> > > presumably) which could be avoided, as the Iterator itself is sufficient
> > > for the above algorithms to work.
> > >
> > > What do you think? Is there any reason not to provide the algorithms for
> > > an Iterator? I personally think that the algorithms should have been
> > > there for Iterators in the first place, because every collection is
> > > Iterable (or has an Iterator, prior to JDK 5.0).
> > >
> > > If noone is interested or has time to implement these changes, I can also
> > > contribute to the project - but at the moment I just wanted to discuss
> > > the idea / check if this has been already considered or planned.
> > >
> > > Best Regards,
> > >
> > > Dusan Chromy
> >
> >
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
