commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject RE: [VOTE][Collections] Naming conventions
Date Tue, 25 Jun 2002 14:11:03 GMT
On Tue, 25 Jun 2002, Waldhoff, Rodney wrote:
> Shouldn't this be covered by the regular commit-then-review process?  

yes, it could have been.  essentially the vote is a preemptive thing to 
formalize the discussion before changes are made.  It's easier to not 
make changes than it is to revert them.

> I haven't followed the (voluminous) threads leading up to this very
> carefully, but to be prefectly honest, it's not clear to me what we're
> voting on.  
> What's "add decorators" mean, precisely?  What's going into SetUtils,
> TreeUtils? Are we voting on taking a bunch of the wrapper classes (e.g.,
> FilterIterator), and hiding them as package-scoped static, inner classes?
> On moving some methods around? Are we voting on a naming convention?
> Specific changes?  On a guideline of having fewer than 60 classes in
> commons.collections?

"decorators" refer to the decorator design pattern.

Examples of a decorator method include 

the "add decorators" means the addition of decorator methods.  For 
example, the ListUtils would have a predicatedList method added which 
constructs a list that ensures its elements match a particular 

The vote is really two-fold, but only really dealing with naming
conventions.  First, the adoption of the naming conventions:

 - XxxUtils classes hold helper/convenience/decorator/etc. methods
related to the Xxx interface.  For example, SetUtils would contain
methods that return a java.util.Set.

 - xxxxedXxx is used as the method name for a particular decorator.  
This matches the pattern used in java.util.Collections to construct 
synchronized and unmodifiable collections/sets/sorted sets/maps

Second, the vote is for refactoring the existing code to match the above 
naming conventions.  Only unreleased classes should be affected, so 
there is no backwards compatibility issues.

The specific addition of wrapper classes as inner classes or whatnot I 
feel is a side effect of the above.  While the vote states that classes 
would be implemented as static inner classes, it also states that this 
could change.  Thus, your vote isn't really for *how* the above naming 
conventions are implemented.  When specific changes are made to bring a 
class in line with the naming conventions, that implementation would be 
subject to the commit-then-review process.  

> Can we make or propose *specific* changes and then vote?  Because I don't
> understand what I'm being asked to vote for.

I'll try to find some time to write up the Naming Conventions 
documentation based on the discussion so that we have something more 
specific to vote on rather than a summary of a discussion.  


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

View raw message