[ http://issues.apache.org/jira/browse/COLLECTIONS-213?page=all ]
Stephen Colebourne updated COLLECTIONS-213: ------------------------------------------- Component/s: Core Issue Type: Improvement (was: New Feature) Fix Version/s: 3.3 > CollectionUtils API extension: algorithm methods accept an Iterator argument > ---------------------------------------------------------------------------- > > Key: COLLECTIONS-213 > URL: http://issues.apache.org/jira/browse/COLLECTIONS-213 > Project: Commons Collections > Issue Type: Improvement > Components: Core > Reporter: Dusan Chromy > Fix For: 3.3 > > Attachments: 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]