These strike me as a Good Idea with merit to be added to [collections]. I am intrigued by your implementation however. The use of Closure requires two new objects (the inner class Closure and the Holder) for each of the key methods including size(). Perhaps you come from a Smalltalk background? Whatever, I fear for performance.
I would have chosen to - store the list of contained collections in an array Collection[] (faster access as the list should be changed relatively infrequently relative to using the combined list) - loop around the array calling size() or isEmpty() or whatever directly. For isEmpty() this can increase performance, as if the first collection returns false you can break the loop. I haven't tested it, but I suspect the performance gain to be noticable, and [collections] has to choose the fastest implementation if it has a choice. Would you consider the alternative implementation I suggest? Stephen ----- Original Message ----- From: "Brian McCallister" <[EMAIL PROTECTED]> > Attached is a CompositeCollection class which allows a single > Collection instance to behave correctly as a composite for N > collections, and unit tests for that class. > > All operations (including iterator removal operations) which are > deterministic per the Collection spec are implemented directly. > Nondeterministic operations (add, addAll) are pluggable and throw an > UnsupportedOperationException if no behavior has been specified. > > Implementations of Set and List (which are dependent upon > CompositeCollection) are forthcoming as soon as I have a chance. > > -Brian > > > ---------------------------------------------------------------------------- ---- > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
