>From a first-scan, it looks like the following classes still need to deprecate and hide behind MapUtils:
SequencedHashMap ReferenceMap MultiHashMap LRUMap [extends SequencedHashMap] none of these really seem to need to implement or extend HashMap [but I could be missing subtleties]. Hen On Wed, 2 Apr 2003, David Graham wrote: > 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 <[EMAIL PROTECTED]> > >Reply-To: "Jakarta Commons Developers List" > ><[EMAIL PROTECTED]> > >To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > >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 <[EMAIL PROTECTED]> > > > >Reply-To: "Jakarta Commons Developers List" > > > ><[EMAIL PROTECTED]> > > > >To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > > >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: [EMAIL PROTECTED] > > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > _________________________________________________________________ > > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > > > http://join.msn.com/?page=features/junkmail > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > > --------------------------------------------------------------------- > 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]
