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 Mon, 17 Jun 2002 17:26:53 GMT
> The resulting changes are:
>  CollectionUtils - add decorators
>  ListUtils - add decorators, undeprecate
>  SetUtils - create with decorators
>  MapUtils - add decorators
>  BagUtils - create with decorators
>  TreeUtils - under consideration
>  IteratorUtils - under consideration
>  ComparatorUtils - rename methods
>  PredicateUtils - separate out decorators
>  FactoryUtils - rename methods
>  TransformerUtils - under consideration
>  LazyCollections - delete with decorators going to ListUtils/MapUtils
>  SimpleObjectFactory - rename to Factory

This all makes me very happy.

> These changes don't break backwards compatability as far as I can see.

Nope; the only modified classes are ListUtils and CollectionUtils,
and we're only *adding* methods, we're not removing anything.  Full
binary compatibility with previous releases.

> Further consideration will be needed of other classes in the 
> API, notably
> the Iterator decorators, as to whether they should be 
> deprecated, or have
> factory methods on IteratorUtils.

I agree that the iterators could use some organization, but 
I'm not thinking that deprecating 10 or so classes will go
over too well. :)

> However, I currently like what is outlined above. Any further 
> views? Does it
> need a vote? And if not, can we record this discussion in a readme or
> something so it is clear to developers as to what the 
> convention is? 

I'm planning to start a documentation campaign once I finish my 
unit testing campaign, and inclusion of a design doc is high up on
my list.

> And  then we can get back to the much more interesting part - coding ;-)

Coding?  What's that?  ;)


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

View raw message