> 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? ;)
-Paul
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|