commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [Collections] Naming conventions
Date Thu, 13 Jun 2002 23:05:16 GMT
> 2) Subclassing would be more complex. Currently each 
> Predicate decorator
> implementation extends another based on the interface 
> hierarchy. In order to
> continue this, the static nested classes would need to be 
> package scoped,
> not private. Not a big issue, but it should be noted.

I'm even okay with the wrapper classes being package-protected
OUTER classes defined in the same source file.  Having 
package-protected classes still gives us a lot of leeway with
organizing things, as technically users shouldn't be using 
package-protected methods and classes.

> After a little thought, I think I favour adding Utils to all 
> of the above.
> Results in no clashes with Java, and just involves adding methods to
> ListUtils, CollectionUtils and MapUtils.

One other consideration is that ListUtils is deprecated.  We 
could always un-deprecate it, of course.  I'd want to manually
deprecate each method currently in the class though, but that
doesn't seem like a big deal.

But otherwise, I think having:


is all good.  I'd like FactoryUtils to be SimpleObjectFactoryUtils,
which is a very long name but more consistent with the others.

> On method names, I agree with your implicit use of   yyyedXxx, eg.
> filteredMap or predicatedSet

This is all sounding dangerously close to consensus!  I think this
is probably the only civilized conversation on naming conventions
I've ever had... :)

> BTW: I thought of two more decorator groups - Transform 
> (already discussed a
> little while back) and FixedSize (doesn't allow the size to 
> change). And I
> like the Comparator to Predicate idea.

A while back I suggested:
  public static Set setBackedByMap(Map map);
  public static SortedSet sortedSetBackByMap(SortedMap map);

which would let people use things like LRUMap as a set.

Composition patterns galore...


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message