commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Wed, 19 Jun 2002 01:52:35 GMT

Ooops. Had started ignoring this thread as an area I lacked experience in
to discuss. Guess it's grown :)

On Wed, 19 Jun 2002, Stephen Colebourne wrote:

> Increase the importance and use of [Lang]

+1 from me. I've been busy trying to learn CLI/Maven/others so haven't
focused on Lang as much as I need to. I really need to push out a strong
series of unit tests for it.

> c) decide on whether the naming convention in [Lang] is xxxs as with Strings
> at present, or xxxUtils as with StringUtils (ie. what [Collections] adopted.

It used to be all xxxUtils and the decision was made to go away from it
when they broke out of the Util sub-project.

> d) consider other additions to [Lang]
>    - a Serialization class, with a method that clones via serialization

Heh. Someone wrote an article on this a year or so back and it's
languished in my xxx.lang package ever since. Am happy to begin by
committing that unless someone has a version they've nurtured into
something more useful.

>    - a StringBuffer class, with the same methods as Strings, but for a
> StringBuffer.

Sounds good. Seems to me there is a better way though. java.lang.String
and StringBuffer don't share that many functionalities from memory. In
Strings the code either manipulates it as a String, or turns it to a
StringBuffer. I would hope that despite having two classes, there would
really only be one implementation method and one method that redirects.
However these methods would not all live in Strings, or all live in
StringBuffers.

I imagine that the StringBuffer methods would pass in a StringBuffer
expecting that to be modified and not to have a StringBuffer returned?? Or
if one is returned [as often is the case in java.lang.StringBuffer] that
it would return the one passed in.

> e) release [Lang] as a full commons project

Won't argue. Lang seems to be cropping up as a project that a few others
are dependant on, so having a release would be nice.

It would be nice to have more unit tests, mavenise it, doc more, hack out
ugly String overloads. The biggest issue I'm finding as I use the methods
is that a lot aren't null safe.

Once Lang is released, then I can release a 1.0 of String taglib depending
on it. So time for me to focus hard on Lang I think.

Hen


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