[ http://issues.apache.org/jira/browse/COLLECTIONS-213?page=all ]

Dusan Chromy updated COLLECTIONS-213:
-------------------------------------

    Attachment: TestCollectionUtils.java

JUnit tests for newly added methods

> CollectionUtils API extension: algorithm methods accept an Iterator argument
> ----------------------------------------------------------------------------
>
>          Key: COLLECTIONS-213
>          URL: http://issues.apache.org/jira/browse/COLLECTIONS-213
>      Project: Commons Collections
>         Type: New Feature

>     Reporter: Dusan Chromy
>  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]

Reply via email to