On Wed, 2 Apr 2003, Rodney Waldhoff wrote:
> On Wed, 2 Apr 2003, Henri Yandell wrote:
>
> >
> > 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
On Wed, 2 Apr 2003, Henri Yandell wrote:
>
> 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?
-1 to making P
On Wed, 2 Apr 2003, Alex Chaffee / Purple Technology wrote:
> Yet another option is to put the static creation methods on the class
> itself:
>
> Map fooMap = FooMap.createFooMapFor(sourceMap);
If the class itself is viewable, then this is fine. It seems the usual
view is to hide the Synchron
Yet another option is to put the static creation methods on the class
itself:
Map fooMap = FooMap.createFooMapFor(sourceMap);
I find this much more natural than going through a separate static
utility class. The ostensible reason for the Java Collections API
putting the creation methods into a
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]>
> >
: 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
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.s
Howdy,
>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 specificat
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 unders
