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.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
