Arun Thomas wrote: >>> The last comment suggests another possibly useful method: >>> toList(), returning an aggregated collection consisting of all of >>> the objects in the composite collections. >> > > In this case, will there be a clever way to return an aggregation of > this sort that isn't simply a new object with copies of all elements > of the contained objects? If that's the case, then is seems more > reasonable to leave the creation of this type of object to the user - > create a new object passing in the composite collection in the > constructor, or use addAll(Collection c). > > If there's a clever way to handle provide the implementation of > List/Set/Collection using the contained collections as a base, that > might be interesting, but otherwise....
That's essentially what the CompositeCollection class does -- decorates the aggregated collections with a Collection interface.
The toCollection(), toList(), etc. stuff would be no different (other than the collection overhead) from toArray(). What would get copied are object references.
Thinking a little more, I suppose that the semantics of both toArray() and toCollection() could be extended to fully flatten what could effectively become a tree of collections. Since CompositeCollection is a Collection, composites could themselves be aggregated (as in Brian's use case above). In this case, extensions of toArray() or toCollection() returning all of the objects nested in the collections might make sense. Of course this applies to ordinary collections as well. Could be that if these methods are useful, they all (including CompositeCollection.toCollection()) belong in CollectionUtils, so instead of CompositeCollection.toCollection(), we just overload CollectionUtils.union(CompositeCollection) (maybe also intersection) and, if the "tree traversal" stuff is useful, we add something like CollectionUtils.traverse(Collection) that unwinds nested collections, returning a flattened list of objects that are not collections (carefully avoiding getting stuck in cycles) and maybe also CollectionUtils.rank(Collection) that returns the integer length of the longest branch in the tree. Individual objects also have ranks -- CollectionUtils.rank(Collection, Object) = level where Object is first encountered in breadth-first search. OK, I will shut up now, starting to sound too much like a logician...Is any of this useful?
Phil > > Cheers, -AMT > > -----Original Message----- From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 05, 2003 8:31 AM To: Jakarta Commons > Developers List Subject: Re: [collections] [PATCH] > CompositeCollection class for Commons-Collections > > > Brian McCallister wrote: > >> On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote: >> >> >>> 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. >> >> >> To quote the Collection API doc: <quote> Removes a single instance >> of the specified element from this collection, if it is present >> (optional operation). More formally, removes an element e such >> that (o==null ? e==null : o.equals(e)), if this collection >> contains one or more such elements. </quote> >> >> I agree that this could be pluggable, but I think that providing a >> "remove first found" as a default is very reasonable in this case >> as it fits the idiomatic behavior people expect from extent >> collections. > > > Note the similarity to the API doc for add: "Ensures that this > collection contains the specified element (optional operation). > Returns true if this collection changed as a result of the call. > (Returns false if this collection does not permit duplicates and > already contains the specified element.)" > > My point is that "kill first" in a composite collection is no more > "natural" than "add last". I would be OK with both being defaulted > but modifiable via Mutator. Since "the collection" could mean either > the aggregate or *each* of the summands in each case, I see both add > and remove as ambiguous (hence the need for strategies). This is a > small point. > > >> +0 (non-binding) for putting this into the CollectionMutator but >> providing present behavior as default if no mutator set (rather >> than an exception as add/addAll do. This is internally inconsistent >> though so I would welcome better ideas. >> >> >>> The containsAll javadoc says "This is O(n^2) at the moment, be >>> careful using it.". >> >> >> It is not correct anymore. It was in the original version but the >> implementation has changed significantly already =) >> >> >>> I am curious about how much faster this can be done without an >>> ordering. >> >> >> Dropping ordering on what? > > > What I meant was that without assuming an ordering on the aggregate > (so binary search would be possible), is there a faster way to do the > "*all" methods. I assume that if there is a clever way to do this, > that is what the JDK methods do. > > >>> The last comment suggests another possibly useful method: >>> toList(), returning an aggregated collection consisting of all of >>> the objects in the composite collections. >> >> >> That works for me, though I would make it a Collection and return >> the actual type of whichever subclass. I suspect Stephen will >> suggest that it be toCollection(), toList(), and toSet() >> respectively in order to allow greater specificity of the return >> type, which I am also okay with. > > > What do you mean by "whichever subclass"? The aggregated collections > could be of multiple different types. That makes an interesting > problem. I suppose that toCollection() could return an instance of > the one common type if the summands are "homogeneous" (all the same > type), otherwise default to a (Array?)List or (Hash?)Set. I agree > that toSet() would also be natural. Need to think about these things > some more. It might be better to just have the API take the > aggregation target as an actual parameter -- i.e. > toCollection(collection), effectively punting the issue of return > types. > > Anyone have any objections to committing this to the decorators > subpackage? > > Phil > > >> Hmm, would be nice if Java let you override a method to return a >> subclass of the return type of the method being overridden. It >> would satisfy the static typing still. >> >> -Brian >> >> PS: I have attached changes discussed >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
