commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <ste...@caswell.name>
Subject RE: [lang] is there a release on the visible horizon?
Date Sun, 30 Jun 2002 16:12:59 GMT
I'm also willing to help get some of this done to move along the release
process. I can take a shot at the simpler stuff, in particular #1 and
#10.

There was a discussion a while ago about the naming convention, and the
general concensus was to not use XxxUtils, but rather Xxxs.  I don't
really care for Xxxs, I'd rather see XxxUtils, so maybe we can revisit
the issue.


Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Sunday, June 30, 2002 8:01 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] is there a release on the visible horizon?
> 
> 
> From: "Henri Yandell" <bayard@generationjava.com>
> > I think there's enough demand out there to get it released. 
> The tiny 
> > size will probably be a plus.
> >
> > Maybe it's time to start thinking about what is left to be 
> done before 
> > a release can be made.
> ...
> > Any other things we need to do?
> 
> Well .............
> 
> 1)  rename method in Objects
> - change isNull() to defaultIfNull()
> 
> 2) add hashCode building methods to Objects, or its own class 
> based on best hashCode practice
> 
> 3) add CharUtils and UStringBuffer and refactor all the 
> Strings code to be shared
> 
> 4) add low level reflection code in reflect subpackage as was 
> discussed a few weeks ago. (needs further discussion)
> 
> 5) examine the Avalon system utilities. Do they go in Lang or 
> elsewhere
> 
> 6) Numbers has a lot of comments about future things. Plus 
> containsDigits() has question marks against the null handling
> 
> 7) Classes clashes badly with the reflection stuff. Either we 
> include reflection or we don't.
> 
> 8) Naming conventions. It seems that every other Commons 
> project is using XxxUtils for their utility names 
> (Collections, BeanUtils, IO, Pattern). It seems that we 
> should at least consider renaming the classes for consistency.
> 
> 9) Constant I don't fully understand. If its meant to be the 
> enumerated type pattern I would suggest:
> - make it abstract
> - make the constructors protected
> - add equals and hashCode methods
> - add extra documentation as to how the subclass should be 
> written What I don't understand is the need for all the 
> different object types. At the most, I would consider String 
> and int  to be all thats needed. (An int would allow it to be 
> Comparable). In fact I would have the Comparable version 
> extend the non-Comparable one (two classes).
> 
> 10) Strings - some methods are very specific (too specific) 
> and could be removed
> - parseObjectKey
> - removeUnderscores
> - translate, it seems unclear as to what its doing
> - reverseDottedName, reverseDelimitedString will do this so 
> is dot a valid special case
> - interpolate - this seems to be very specific to a particular syntax
> 
> Some methods have misleading names
> - isValid() - should be isNotEmpty(), a not empty string is 
> not necessarily valid
> 
> Some methods could be optimised:
> - capitalise
> - uncapitalise
> - overlayString
> 
> Some methods may be wrong:
> - chomp/chompLast  hard codes \n rather than uses 
> System.LINE_SEPARATOR
> - wordWrap  hard codes \n rather than uses System.LINE_SEPARATOR
> 
> The class seems too big. Maybe some smaller associated 
> utility classes would be appropriate? CharSet methods seem to 
> be a group. Could they be in their own class? Also why is 
> evaluateSet public when a CharSet cannot be passed in anywhere.
> (PatternStringUtils)
> Maybe the casing methods could be broken out?    (CaseStringUtils)
> Maybe the random methods could be broken out?   (RandomStringUtils)
> 
> Add
> - left(String, int len), right(String, int len) and 
> mid(String, int from, int len) to Strings, no exceptions  (as 
> per BASIC)
> - isAlphanumericSpace/isNumericSpace, for specifically space 
> and not whitespace
> - contains(String, String), does the first string contain the second
> 
> 
> Well the list was longer than I thought it was going to be... 
> Not all of these have to be done before 1.0, but quite a few 
> do (to avoid horrible deprecations). I don't think that many 
> of these will take that long, and I'm willing to help. So, 
> maybe we could hold off for a little while?
> 
> Stephen
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 



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