commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] is there a release on the visible horizon?
Date Sun, 30 Jun 2002 19:55:18 GMT

Attempting to plod through and answer bits in these.

After a few more emails I'll mail a new list of todo items.


On Sun, 30 Jun 2002, Stephen Colebourne wrote:

> 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

Sounds like a nice idea. Could you start a separate thread to discuss
the best practices and what this could do. A new feature, so could spend
lots of debating time.

> 3) add CharUtils and UStringBuffer and refactor all the Strings code to be
> shared

Which do we declare to be most important. If we refactor to share code,
then where do we choose to lose performance? UStringBuffer won't be able
to extend StringBuffer. I'd like to thread this off into another
conversation, similar to 2).

> 4) add low level reflection code in reflect subpackage as was discussed a
> few weeks ago. (needs further discussion)

I think this is worthwhile getting in. Another separate topic.

> 5) examine the Avalon system utilities. Do they go in Lang or elsewhere

I'd prefer to hold this one off until after a 1.0.

> 6) Numbers has a lot of comments about future things. Plus containsDigits()
> has question marks against the null handling

Question marks meaning, should containsDigit consider null to contain
digits or not, or should it not even check.

> 7) Classes clashes badly with the reflection stuff. Either we include
> reflection or we don't.

Hopefully we can integrate them. Classes would appear to have a place in
that it faces java.lang.Class, but maybe there are no real methods to add
here. There are System.err.println's in Classes which aren't too stunning.
Do we follow the poor java.lang convention of Class in lang but Method etc
in lang.reflect? Or just have the Class features in lang.reflect too.

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

Need to dredge up the old emails about the pros and cons. The XxxUtils
seems an ugly convention just to say 'this class is made up of static
methods for dealing with Xxx'.

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

Constant is not meant to be a full enumerated type. It is driven by the
number of people who do:  public static int SKY_MAGIC = 5;
A terrible thing (imo) which means that the API is full of doMagic(int).
The primary idea of Constant is to make it obvious in an API where the
magic numbers are. From an OO purist point of view, maybe I should be
making an object for every magic number, ie) Enum.

The reason for having it as a concrete class is to not force people to
have to type every magic number they have.

There is no equals method because I believe this would be wrong.

Constant c1 = new Constant("c1"); and
Constant c2 = new Constant("c1"); should not be equal. I shouldn't be able
to say:

if(MAGIC_NUMBER.equals(new Constant("c1"))) {

as I quite obviously haven't gone to Magic.MAGIC_NUMBER to get my value.

Only having String and int is no good if I want to do a constant for PI
[please ignore it already existing].

Biggest issue to me on Constant is that I have discovered it has
Serialisation problems, might have to scrap it for this alone as I've not
found a solution without making it an Enum structure.

> 10) Strings - some methods are very specific (too specific) and could be
> removed
> - parseObjectKey
> - removeUnderscores

These are quite old. We might want to enquire as to who is dependant on
them and then kill them.

> - translate, it seems unclear as to what its doing

Unix tr style thingy :)

> - reverseDottedName, reverseDelimitedString will do this so is dot a valid
> special case

Sounds good.

> - interpolate - this seems to be very specific to a particular syntax

I think it is quite a standard syntax, but also not something that needs
to live inside Strings. org.apache.commons.util.BasicInterpolator would be
my vote.

> 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

Go for it. I don't pretend to be a great algorithm coder.

> 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

Definitely for LINE_SEPARATOR. chomp stuff needs a bit of investigating as
I was following the PHP versions a bit closely.

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

CharSet used to be a public class. It was put into Strings for
organisational purposes while it lived in the Util project and hasn't been
broken out again.

> (PatternStringUtils)
> Maybe the casing methods could be broken out?    (CaseStringUtils)

People expect these to be in Strings I think.

> Maybe the random methods could be broken out?   (RandomStringUtils)

I think this would be a good thing.

> Add
> - left(String, int len), right(String, int len) and mid(String, int from,
> int len) to Strings, no exceptions  (as per BASIC)

So what do these do? Didn't have them in BBC BASIC in 1984 :)

> - isAlphanumericSpace/isNumericSpace, for specifically space and not
> whitespace
> - contains(String, String), does the first string contain the second

+1 to both.

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

View raw message