Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Class: urn:content-classes:message
Message-ID: <3FD543CF.2090409@steitz.com>
Date: Mon, 08 Dec 2003 20:38:55 -0700
From: "Phil Steitz" <phil@steitz.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
MIME-Version: 1.0
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [collections] [contribution] CompositeSet and CompositeMap
References: <BAY9-F57LdvlXta3ElZ0001b4c4@hotmail.com>
 <1C2E84F8-2824-11D8-AA34-000A95782782@apache.org>
 <004901c3bc68$92e1d440$b32a8051@oemcomputer>
 <9F284776-286F-11D8-ADA2-000A95782782@forthillcompany.com>
 <004e01c3bd1f$688b47a0$f2698051@oemcomputer>
 <3D18A972-2913-11D8-92B3-000A95782782@forthillcompany.com>
Content-Type: text/plain;
	format=flowed;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Brian McCallister wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Dec 7, 2003, at 7:08 PM, Stephen Colebourne wrote:
> 
>> I think that they probably are useful additions, however the review and
>> commit may take some time :-)
> 
> 
> No worries =) I don't have an immediate or near future need for them to 
> be in commons-collections -- they can live happily on their own working 
> against the present release. I just thought that they would fit well so 
> wanted to contribute them.
> 
> I'll try to keep an eye on this list for discussion in the future on 
> them when someone has a chance to review, but it is high enough volume 
> that things slip through sometimes.

Brian,

I had a look.  I now see the changes necessary to the CompositeCollection 
class and my previous comments on the earlier submission still hold:


Housekeeping:

* Please try to follow the [collections] style for braces.

Substantive:

Why does CompositeSet extend CompositeCollection? The setup looks a bit 
strained to me (e.g. the type checking in the addComposited method).

Looking carefully at what addComposited does in CompositeSet, I am not 
sure that I understand what CompositeSet and CompositeMap are trying to 
do.  I understood CompositeCollection to be a convenient way to decorate a 
  collection of Collections to provide a unified view.  Once you try to 
control "collisions", as in the Set and Map impls, you seem to be headed 
for some kind of partition concept.  Is that what you had in mind?  Also, 
since add() and resolveCollisions() are separate methods in the mutator 
interface, one could presumably do inconsistent things -- i.e., allow 
"duplicates" to be added directly via add() but disallow them in 
addComposited() by having resolveCollisions prevent duplicates.

Can you explain a little more what the use cases for these things are?

Phil


> 
> - -Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (Darwin)
> 
> iD8DBQE/08H+aOuMdvjqKWcRAjQUAJ49yLhytK5FWZae1FzSEW+LtlkwvwCfR71C
> LJchgJsHh5ugSoK8V5mrbvY=
> =u7Ze
> -----END PGP SIGNATURE-----
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org