commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <...@apache.org>
Subject RE: [Collections] Naming conventions
Date Mon, 17 Jun 2002 18:03:43 GMT
On Mon, 17 Jun 2002, Jack, Paul wrote:
> > 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.

it makes me happy as long as there are tests for each of them.  :)

> > 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.

agreed. 

> > 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. :)

Deprecating is just a way of saying its not the preferred mechanism for
the functionality.  It doesn't necessarily mean we are going to remove
them.  I'm not against deprecating the iterators (are there really 10?  
I didn't think there were that many), although I would be if we were
planning on removing them.  Maybe after a few releases of deprecation we
could *consider* removing them and plan for removal in a future release,
but now is too soon.

> > 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 not sure we need to take a formal vote.  Everyone participating on
the mailing list seems to agree (either implicitly by not saying
anything or with explicit approval).  I'll commit it into CVS tonight
and if anyone objects, they can just -1 my patch and we'll see if we can
address the reasons for the veto.

> 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.

As far as your unit test campaign goes, I'm almost done going through
them.  I've got eight phases worked through right now, each building on
the previous.  I'm hoping to wrap them up and get them committed this
evening.

> > And  then we can get back to the much more interesting part - coding ;-)
> 
> Coding?  What's that?  ;)

:)

regards,
michael


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message