commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject Re: [collections] Collections Next Gen
Date Wed, 02 Apr 2003 17:22:04 GMT
An alternative approach to using MapUtils.sequencedMap(Map) and similar 
methods in ListUtils, etc. would be to group those wrapping methods in 
CollectionUtils.  That would be similar to how Java groups the wrapping in 
the Collections class.  Either placement is fine with me.

David



>From: Henri Yandell <bayard@generationjava.com>
>Reply-To: "Jakarta Commons Developers List" 
><commons-dev@jakarta.apache.org>
>To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>Subject: Re: [collections] Collections Next Gen
>Date: Wed, 2 Apr 2003 12:08:21 -0500 (EST)
>
>
>That's fine.
>
>So ProxyMap is special, all ProxyMap implementations should be
>package-private and available through a MapUtils class and can have
>constructors which take a collection as copy-by-reference as it's not a
>public API?
>
>So, SequencedHashMap would be deprecated and removed, and
>MapUtils.sequencedMap(Map) added?
>
>Hen
>
>On Wed, 2 Apr 2003, David Graham wrote:
>
> > The Java collections all use your number 1 approach.  I believe it would 
>be
> > very confusing for users if commons-collections behaved differently.  An
> > example of the Java collections wrapping technique is
> > Collections.synchronizedMap(Map).  Using this technique would be 
>familiar
> > and easy to understand for users.
> >
> > David
> >
> >
> >
> > >From: Henri Yandell <bayard@generationjava.com>
> > >Reply-To: "Jakarta Commons Developers List"
> > ><commons-dev@jakarta.apache.org>
> > >To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> > >Subject: [collections] Collections Next Gen
> > >Date: Wed, 2 Apr 2003 11:54:47 -0500 (EST)
> > >
> > >
> > >I'm aiming to restructure the Collections API a bit. Basically an
> > >annoyance at things like:
> > >
> > >SequencedHashMap, when the Hash part of it shouldn't be there. Ditto 
>for
> > >MultiHashMap etc etc.
> > >
> > >I've one question I'd like to air-out first though:
> > >
> > >ProxyMap has a constructor which takes a Map. It uses this map as the 
>map
> > >it will proxy to. This is against the Collections spec, which says that 
>a
> > >java.util.Map implementation [and other Collections] should treat a
> > >constructor argument of a Map as values to copy across. ie) 
>copy-by-value
> > >rather than copy-by-reference I guess.
> > >
> > >I'd like to standardise this as either something we obey, or don't 
>obey.
> > >Personally I've never liked it and not obeyed it, as a putAll or addAll
> > >method easily handles this functionality. Usually the Collections 
>project
> > >has obeyed it however, as it is an unwritten part of the specification 
>we
> > >are obeying. It seems we have three options I think:
> > >
> > >
> > >1) We strictly obey the specification. A collection-type parameter to a
> > >constructor is a copy-by-value.
> > >
> > >2) We strictly obey our own specification, saying that collection-type
> > >parameters mean wrapping.
> > >
> > >3) Any extension of ProxyMap uses copy-by-reference as its 
>specification.
> > >So when I pass a HashMap() into a SequencedMap, it uses that HashMap as
> > >its underlying structure.
> > >    Any other extension of a Map uses copy-by-value, so if I pass a 
>HashMap
> > >into a new FastHashMap, it copies the values from the HashMap into the
> > >FastHashMap.
> > >
> > >
> > >I prefer number 3. My aim is to make the majority of the Collections
> > >classes extensions of ProxyXxx classes. Anyone -1?
> > >
> > >Hen
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > _________________________________________________________________
> > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > http://join.msn.com/?page=features/junkmail
> >
> >
> > ---------------------------------------------------------------------
> > 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
>


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus


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


Mime
View raw message