commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <mich...@iammichael.org>
Subject RE: [VOTE][Collections] Naming conventions
Date Sat, 29 Jun 2002 03:50:26 GMT
Thanks to Stephen, we now have a "DEVELOPERS-GUIDE" which 
explicitly lists the conventions we are voting on.  The commit will act 
as a standard commit-then-review, so if you have problems with the 
conventions, -1 the commit with your reasons and we'll work from there.

http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/collections/DEVELOPERS-GUIDE.html

regards,
michael

On Tue, 25 Jun 2002, Michael A. Smith wrote:
> 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. 
> http://www.castle-cadenza.demon.co.uk/decorate.htm
> http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/DecoratorPattern.htm
> http://www.mindspring.com/~mgrand/pattern_synopses.htm#Decorator
> 
> Examples of a decorator method include 
>   java.util.Collections#synchronizedSet(Set)
>   java.util.Collections#unmodifiableMap(Map)
> 
> 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 
> predicate.
> 
> 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.  
> 
> 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