commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [collections] [PATCH] CompositeCollection class for Commons-Collections
Date Wed, 05 Nov 2003 05:10:31 GMT
Stephen Colebourne wrote:
> I've updated the class in line with commons standards/documentation etc. It
> will probably end up in the decorators subpackage, as it decorates other
> collections.
> I've also changed the way the Mutator works - see what you think, it seems
> cleaner/quicker I think.
> The test case still needs looking at as it doesn't extend the collections
> testframework.
> Any other [collections] committers care to comment on the
> idea/implementation????
> Stephen

Looks good and useful to me.  Here are some specific comments:

I think that that javadoc for remove is incorrect when it says:
"This implementation calls <code>remove()</code> on each collection." 
It stops when it finds the element to be removed.  The contract needs to 
be made more explicit here.  It might actually be better to push 
remove() into the Mutator, since one could argue that the current 
"remove strategy" (kill the first one found) is no less arbitrary than a 
default "add" strategy that just adds to the last collection.  Might be 
better to make this pluggable like add.

The containsAll javadoc says "This is O(n^2) at the moment, be careful 
using it.".  I am not sure that this is correct; but in any case it does 
have to linearly search the composite collection for each element in the 
   collection passed in.  I am curious about how much faster this can be 
done without an ordering. Does anyone know how the JDK containsAll does 
it for, say, ArrayLists?

The last comment suggests another possibly useful method:
toList(), returning an aggregated collection consisting of all of the 
objects in the composite collections.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message