commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] is there a release on the visible horizon?
Date Sun, 30 Jun 2002 13:00:39 GMT
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>


Mime
View raw message