You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/07/01 01:29:33 UTC

Re: [lang] is there a release on the visible horizon?

From: "Henri Yandell" <ba...@generationjava.com>
> On Sun, 30 Jun 2002, Stephen Colebourne wrote:
> > 1)  rename method in Objects
> > - change isNull() to defaultIfNull()
>
> +1.
Done

> > 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.
Or should it throw an exception (and which one)


> > 9) Constant
...
> 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.
I would favour a structure more like Enum. Maybe I should checkin my
classes, and they could be -1ed or Constant removed as appropriate.


> > 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.
How do we do that? Just delete them and see if anyone complains?

> > - reverseDottedName, reverseDelimitedString will do this so is dot a
valid
> > special case
>
> Sounds good.
TODO

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

> > Some methods have misleading names
> > - isValid() - should be isNotEmpty(), a not empty string is not
necessarily
> > valid
> +1.
TODO

> > Some methods could be optimised:
> > - capitalise
> > - uncapitalise
> > - overlayString
> Go for it. I don't pretend to be a great algorithm coder.
TODO

> > 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.
TODO (change to LINE SEP)
I'll let you worry about the methods in general.

> > 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.
But do you agree with a new class taking the static methods as well? In fact
do they become instance methods?

> > (PatternStringUtils)
> > Maybe the casing methods could be broken out?    (CaseStringUtils)
>
> People expect these to be in Strings I think.
They do form a nice group. And could be broken out.

 > > Maybe the random methods could be broken out?   (RandomStringUtils)
>
> I think this would be a good thing.
TODO

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

Yes you did ;-) And on the Archimedes too.
left(String str, int len)  is the same as substring(0, len) but returns the
string without exceptions if length < len
right(String str, int len)  is the same as substring(str.length() - len) but
returns the string without exceptions if length < len
mid(String str, int start, int len)  is the same as substring(start, len)
but returns the remainder of the string without exceptions if len chars not
available

> > - isAlphanumericSpace/isNumericSpace, for specifically space and not
> > whitespace
> > - contains(String, String), does the first string contain the second
>
> +1 to both.
TODO



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch NumbersTest.java

Posted by Rand McNeely <ra...@yahoo.com>.

Noticed a problem with the patch for Numbers.java.  Please use this one
instead.

> -----Original Message-----
> From: Rand McNeely [mailto:rand_mcneely@yahoo.com]
> Sent: Tuesday, July 02, 2002 7:06 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [lang] patch NumbersTest.java
> 
> Here's the fix.  I had to completely rewrite the method.  I've
attached
> the patch for Numbers.java, build.xml and I've attached
> NumbersTest.java.
> 
> Here's the new logic for createNumber(String val)..
> 
> If it has a type qualifier on the end (l, d, f, etc), start with the
> Specified class and work your way up until you find one that will hold
> it.
> 
> Otherwise, start from Float/Integer and keep trying all the way until
> BigDecimal/BigInteger.
> 
> All else fails, try hex.
> 
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Tuesday, July 02, 2002 2:26 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] NumbersTest.java
> >
> > Yes, it looks like the intention of the code is to return the
correct
> > type,
> > and thus it should treat the letters f, d, l as more important than
> > trusting
> > the java methods. Both cases should be handled. Both should drop
back
> to
> > BigDeciomal/BigInteger as appropriate.
> >
> > Can you fix the class, expanding on the javadoc to explain how it
> works?
> > I'd
> > rather hold off on the test just until it runs without errors ;-)
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Rand McNeely" <ra...@yahoo.com>
> > To: "'Jakarta Commons Developers List'"
> <co...@jakarta.apache.org>
> > Sent: Tuesday, July 02, 2002 4:16 AM
> > Subject: [lang] NumbersTest.java
> >
> >
> > >
> > >
> > > One of the tests is actually failing (createNumber(String) 3) on
JDK
> > > 1.4.  If I am understanding the intentions of createNumber, it
> should
> > > return a Double when passed "1234.5D" but it is returning a Float.
> It
> > > looks like Float.valueOf(String) is not throwing a
> NumberFormatException
> > > for "1234.5D" as you would expect (Long.valueOf(String) will throw
> an
> > > exception for "12345L") - a small inconsistency in the JDK.
> > >
> > > Should we modify the logic to first check for F's or D's before
the
> > > indiscriminately calling createFloat and createDouble?
> > >
> > > Rand
> > >
> > >
> > >
> >
> >
> >
>
------------------------------------------------------------------------
> --
> > --
> > ----
> >
> >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@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>

RE: [lang] patch NumbersTest.java

Posted by Rand McNeely <ra...@yahoo.com>.

Here's the fix.  I had to completely rewrite the method.  I've attached
the patch for Numbers.java, build.xml and I've attached
NumbersTest.java.

Here's the new logic for createNumber(String val)..

If it has a type qualifier on the end (l, d, f, etc), start with the 
Specified class and work your way up until you find one that will hold
it.

Otherwise, start from Float/Integer and keep trying all the way until
BigDecimal/BigInteger.  

All else fails, try hex.

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Tuesday, July 02, 2002 2:26 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] NumbersTest.java
> 
> Yes, it looks like the intention of the code is to return the correct
> type,
> and thus it should treat the letters f, d, l as more important than
> trusting
> the java methods. Both cases should be handled. Both should drop back
to
> BigDeciomal/BigInteger as appropriate.
> 
> Can you fix the class, expanding on the javadoc to explain how it
works?
> I'd
> rather hold off on the test just until it runs without errors ;-)
> 
> Stephen
> 
> ----- Original Message -----
> From: "Rand McNeely" <ra...@yahoo.com>
> To: "'Jakarta Commons Developers List'"
<co...@jakarta.apache.org>
> Sent: Tuesday, July 02, 2002 4:16 AM
> Subject: [lang] NumbersTest.java
> 
> 
> >
> >
> > One of the tests is actually failing (createNumber(String) 3) on JDK
> > 1.4.  If I am understanding the intentions of createNumber, it
should
> > return a Double when passed "1234.5D" but it is returning a Float.
It
> > looks like Float.valueOf(String) is not throwing a
NumberFormatException
> > for "1234.5D" as you would expect (Long.valueOf(String) will throw
an
> > exception for "12345L") - a small inconsistency in the JDK.
> >
> > Should we modify the logic to first check for F's or D's before the
> > indiscriminately calling createFloat and createDouble?
> >
> > Rand
> >
> >
> >
> 
> 
>
------------------------------------------------------------------------
--
> --
> ----
> 
> 
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@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>

Re: [lang] NumbersTest.java

Posted by Henri Yandell <ba...@generationjava.com>.

I guess that Numbers needs to support all the add, divide, min methods for
Number that BigDecimal has for itself.

Soon have this writing finished, just 3 more tips to go. Need to quit
this job :)

Hen

On Tue, 2 Jul 2002, Stephen Colebourne wrote:

> Yes, it looks like the intention of the code is to return the correct type,
> and thus it should treat the letters f, d, l as more important than trusting
> the java methods. Both cases should be handled. Both should drop back to
> BigDeciomal/BigInteger as appropriate.
>
> Can you fix the class, expanding on the javadoc to explain how it works? I'd
> rather hold off on the test just until it runs without errors ;-)
>
> Stephen
>
> ----- Original Message -----
> From: "Rand McNeely" <ra...@yahoo.com>
> To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
> Sent: Tuesday, July 02, 2002 4:16 AM
> Subject: [lang] NumbersTest.java
>
>
> >
> >
> > One of the tests is actually failing (createNumber(String) 3) on JDK
> > 1.4.  If I am understanding the intentions of createNumber, it should
> > return a Double when passed "1234.5D" but it is returning a Float.  It
> > looks like Float.valueOf(String) is not throwing a NumberFormatException
> > for "1234.5D" as you would expect (Long.valueOf(String) will throw an
> > exception for "12345L") - a small inconsistency in the JDK.
> >
> > Should we modify the logic to first check for F's or D's before the
> > indiscriminately calling createFloat and createDouble?
> >
> > Rand
> >
> >
> >
>
>
> ----------------------------------------------------------------------------
> ----
>
>
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] NumbersTest.java

Posted by Stephen Colebourne <sc...@btopenworld.com>.

Yes, it looks like the intention of the code is to return the correct type,
and thus it should treat the letters f, d, l as more important than trusting
the java methods. Both cases should be handled. Both should drop back to
BigDeciomal/BigInteger as appropriate.

Can you fix the class, expanding on the javadoc to explain how it works? I'd
rather hold off on the test just until it runs without errors ;-)

Stephen

----- Original Message -----
From: "Rand McNeely" <ra...@yahoo.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Tuesday, July 02, 2002 4:16 AM
Subject: [lang] NumbersTest.java


>
>
> One of the tests is actually failing (createNumber(String) 3) on JDK
> 1.4.  If I am understanding the intentions of createNumber, it should
> return a Double when passed "1234.5D" but it is returning a Float.  It
> looks like Float.valueOf(String) is not throwing a NumberFormatException
> for "1234.5D" as you would expect (Long.valueOf(String) will throw an
> exception for "12345L") - a small inconsistency in the JDK.
>
> Should we modify the logic to first check for F's or D's before the
> indiscriminately calling createFloat and createDouble?
>
> Rand
>
>
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[lang] NumbersTest.java

Posted by Rand McNeely <ra...@yahoo.com>.


One of the tests is actually failing (createNumber(String) 3) on JDK
1.4.  If I am understanding the intentions of createNumber, it should
return a Double when passed "1234.5D" but it is returning a Float.  It
looks like Float.valueOf(String) is not throwing a NumberFormatException
for "1234.5D" as you would expect (Long.valueOf(String) will throw an
exception for "12345L") - a small inconsistency in the JDK.

Should we modify the logic to first check for F's or D's before the
indiscriminately calling createFloat and createDouble?

Rand

Re: [lang] [patch] Numbers.containsDigits(String)

Posted by Stephen Colebourne <sc...@btopenworld.com>.

From: "Rand McNeely" <ra...@yahoo.com>
> I'll be happy to write the unit test.
;-)

> rename containsDigits to isOnlyDigits ("a9ez" contains digits)
I agree, we need to confer on this however

> and as noted there may be some performance issues in the
> isNumber(String) method.
Probably not worth worrying about

>  Also, is there a reason we don't have a maximum(int,int,int) for
> completeness (as far as that goes, what about longs, etc - perhaps the
> method should be changed to use longs instead of ints)?
I added maximum as I checked in your patch.

> Other methods that might be nice but can wait until a 1.0 release are
> operators for the primitive wrappers (add(Integer a,Integer b), etc).
+1, but less important than the tests

Stephen

> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Monday, July 01, 2002 6:46 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] [patch] Numbers.containsDigits(String)
> >
> > Patch applied, thanks.
> >
> > Are there any more changes you want to make to Numbers? (If you'd like
> to
> > help a Numbers unit test would be useful!)
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Rand McNeely" <ra...@yahoo.com>
> > To: "'Jakarta Commons Developers List'"
> <co...@jakarta.apache.org>
> > Sent: Tuesday, July 02, 2002 12:06 AM
> > Subject: [lang] [patch] Numbers.containsDigits(String)
> >
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > > Sent: Monday, July 01, 2002 6:02 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [lang] is there a release on the visible horizon?
> > > >
> > > > +1, please submit a patch
> > > >
> > > > Stephen
> > > >
> > > > ----- Original Message -----
> > > > From: "Rand McNeely" <ra...@yahoo.com>
> > > > To: "'Jakarta Commons Developers List'"
> > > <co...@jakarta.apache.org>
> > > > Sent: Monday, July 01, 2002 10:41 PM
> > > > Subject: RE: [lang] is there a release on the visible horizon?
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > > > 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.
> > > > > > Or should it throw an exception (and which one)
> > > > > >
> > > > >
> > > > > I think the current implementation for nulls is fine but there
> is
> > > one
> > > > > other problem, the method will return true if passed "".  I can
> go
> > > ahead
> > > > > and take care of this.
> > > > >
> > > > > Rand
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@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>
> > >
> >
> >
> >
> ------------------------------------------------------------------------
> --
> > --
> > ----
> >
> >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@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>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] [patch] Numbers.containsDigits(String)

Posted by Rand McNeely <ra...@yahoo.com>.

I'll be happy to write the unit test.

As far as the class in general, I would...

rename containsDigits to isOnlyDigits ("a9ez" contains digits) 

and as noted there may be some performance issues in the
isNumber(String) method. 

 Also, is there a reason we don't have a maximum(int,int,int) for
completeness (as far as that goes, what about longs, etc - perhaps the
method should be changed to use longs instead of ints)?

Other methods that might be nice but can wait until a 1.0 release are
operators for the primitive wrappers (add(Integer a,Integer b), etc).

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Monday, July 01, 2002 6:46 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] [patch] Numbers.containsDigits(String)
> 
> Patch applied, thanks.
> 
> Are there any more changes you want to make to Numbers? (If you'd like
to
> help a Numbers unit test would be useful!)
> 
> Stephen
> 
> ----- Original Message -----
> From: "Rand McNeely" <ra...@yahoo.com>
> To: "'Jakarta Commons Developers List'"
<co...@jakarta.apache.org>
> Sent: Tuesday, July 02, 2002 12:06 AM
> Subject: [lang] [patch] Numbers.containsDigits(String)
> 
> 
> >
> >
> > > -----Original Message-----
> > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > Sent: Monday, July 01, 2002 6:02 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [lang] is there a release on the visible horizon?
> > >
> > > +1, please submit a patch
> > >
> > > Stephen
> > >
> > > ----- Original Message -----
> > > From: "Rand McNeely" <ra...@yahoo.com>
> > > To: "'Jakarta Commons Developers List'"
> > <co...@jakarta.apache.org>
> > > Sent: Monday, July 01, 2002 10:41 PM
> > > Subject: RE: [lang] is there a release on the visible horizon?
> > >
> > >
> > > >
> > > > >
> > > > > > > 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.
> > > > > Or should it throw an exception (and which one)
> > > > >
> > > >
> > > > I think the current implementation for nulls is fine but there
is
> > one
> > > > other problem, the method will return true if passed "".  I can
go
> > ahead
> > > > and take care of this.
> > > >
> > > > Rand
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@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>
> >
> 
> 
>
------------------------------------------------------------------------
--
> --
> ----
> 
> 
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@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>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] [patch] Numbers.containsDigits(String)

Posted by Stephen Colebourne <sc...@btopenworld.com>.

Patch applied, thanks.

Are there any more changes you want to make to Numbers? (If you'd like to
help a Numbers unit test would be useful!)

Stephen

----- Original Message -----
From: "Rand McNeely" <ra...@yahoo.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Tuesday, July 02, 2002 12:06 AM
Subject: [lang] [patch] Numbers.containsDigits(String)


>
>
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Monday, July 01, 2002 6:02 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] is there a release on the visible horizon?
> >
> > +1, please submit a patch
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Rand McNeely" <ra...@yahoo.com>
> > To: "'Jakarta Commons Developers List'"
> <co...@jakarta.apache.org>
> > Sent: Monday, July 01, 2002 10:41 PM
> > Subject: RE: [lang] is there a release on the visible horizon?
> >
> >
> > >
> > > >
> > > > > > 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.
> > > > Or should it throw an exception (and which one)
> > > >
> > >
> > > I think the current implementation for nulls is fine but there is
> one
> > > other problem, the method will return true if passed "".  I can go
> ahead
> > > and take care of this.
> > >
> > > Rand
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@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>
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[lang] [patch] Numbers.containsDigits(String)

Posted by Rand McNeely <ra...@yahoo.com>.


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Monday, July 01, 2002 6:02 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] is there a release on the visible horizon?
> 
> +1, please submit a patch
> 
> Stephen
> 
> ----- Original Message -----
> From: "Rand McNeely" <ra...@yahoo.com>
> To: "'Jakarta Commons Developers List'"
<co...@jakarta.apache.org>
> Sent: Monday, July 01, 2002 10:41 PM
> Subject: RE: [lang] is there a release on the visible horizon?
> 
> 
> >
> > >
> > > > > 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.
> > > Or should it throw an exception (and which one)
> > >
> >
> > I think the current implementation for nulls is fine but there is
one
> > other problem, the method will return true if passed "".  I can go
ahead
> > and take care of this.
> >
> > Rand
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@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>