You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Steven Caswell <st...@caswell.name> on 2002/06/26 23:00:59 UTC
[lang] is there a release on the visible horizon?
Is there a release on the visible horizon? I'd especially like to get
the Nestable exception package available.
Steven Caswell
steven@caswell.name
--
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>
Re: [lang] is there a release on the visible horizon?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
+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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] is there a release on the visible horizon?
Posted by Rand McNeely <ra...@yahoo.com>.
>
> > > 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>
Re: [lang] is there a release on the visible horizon?
Posted by Henri Yandell <ba...@generationjava.com>.
> > > 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.
It'd be great to have an Enum set, though it seems something that many
people have done and will have different requirements for, so will
probably undergo changes for a while.
> > > 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?
Cvs log, email, then rm.
> > > 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?
+1 on the new class taking the static methods. Whether people should think
in terms of CharSets or char[]'s though I'm unsure. Possibly static
methods which call instance methods. I tend to like want to keep things
open a bit too much sometimes.
> > > 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
Now I'm going to have to head back to my parents and dredge out the beeb
and manual :)
+1 on these funcs.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] is there a release on the visible horizon?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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] is there a release on the visible horizon?
Posted by Henri Yandell <ba...@generationjava.com>.
Attempting to plod through and answer bits in these.
After a few more emails I'll mail a new list of todo items.
Hen
On Sun, 30 Jun 2002, Stephen Colebourne wrote:
> Well .............
>
> 1) rename method in Objects
> - change isNull() to defaultIfNull()
+1.
>
> 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
+1.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] [patch] Optimizations for Strings methods
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Patch applied. Thanks
Stephen
----- Original Message -----
From: "Rand McNeely" <ra...@yahoo.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Monday, July 01, 2002 7:31 AM
Subject: [lang] [patch] Optimizations for Strings methods
> > Some methods could be optimised:
> > - capitalise
> > - uncapitalise
> > - overlayString
>
> I worked on these optimizations basically replacing the string concats
> with StringBuffers ensuring the correct capacity in the constructor. I
> have attached the patch.
>
> Btw, as I am very new to open source, if I am making some faux pas here
> please let me know so I can stop embarrassing myself :)
>
> 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>
Re: [lang] [patch] Optimizations for Strings methods
Posted by Henri Yandell <ba...@generationjava.com>.
Nope, looks fine to me. I'll add applying the patch to the list of todo's.
I won't be finding much time to do things until Wed night, so don't panic
if it hasn't gone in by then. Tight deadlines for two jobs coinciding :(
Hen
On Mon, 1 Jul 2002, Rand McNeely wrote:
> > Some methods could be optimised:
> > - capitalise
> > - uncapitalise
> > - overlayString
>
> I worked on these optimizations basically replacing the string concats
> with StringBuffers ensuring the correct capacity in the constructor. I
> have attached the patch.
>
> Btw, as I am very new to open source, if I am making some faux pas here
> please let me know so I can stop embarrassing myself :)
>
> Rand
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang] [patch] Optimizations for Strings methods
Posted by Rand McNeely <ra...@yahoo.com>.
> Some methods could be optimised:
> - capitalise
> - uncapitalise
> - overlayString
I worked on these optimizations basically replacing the string concats
with StringBuffers ensuring the correct capacity in the constructor. I
have attached the patch.
Btw, as I am very new to open source, if I am making some faux pas here
please let me know so I can stop embarrassing myself :)
Rand
Re: [lang] is there a release on the visible horizon?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@mac.com>
> On Sunday, June 30, 2002, at 02:00 PM, Stephen Colebourne wrote:
> > From: "Henri Yandell" <ba...@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.
>
> <snip>
>
> > 4) add low level reflection code in reflect subpackage as was discussed
a
> > few weeks ago. (needs further discussion)
>
> (FYI there is (at least) one fix which needs to be made to the reflection
> code in beanutils.)
>
> IMHO there isn't really any point holding up the initial release to get
> this in.
>
> are you going to try for promotion to the commons before the release?
>
> it'd be a lot easier to move the reflection code into lang if lang were
> already a commons component.
I have one problem with (4) waiting until after a 1.0 release. And that is
item (7):
>>7) Classes clashes badly with the reflection stuff. Either we include
>>reflection or we don't.
In other words I'm not fussed about the protocol of whether its a sandbox or
commons proper component. But I do want to get the release of Lang right so
we don't need to deprecate Classes later. That's more important to me.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] New feature: Close method for Objects
Posted by robert burrell donkin <ro...@mac.com>.
On Monday, July 1, 2002, at 06:08 AM, Henri Yandell wrote:
<snip>
>> Also, I am new to all of this, could someone please explain this +1, -1
>> stuff :)
>
> +1 = I'm in favour of this and will help.
> +0 = I'm in favour of this, but lack time to help.
> -0 = I'm against this, but don't consider myself to be blocking it.
> -1 = I'm against this and am blocking this happening.
>
> When something is voted on, 3 +1 and no -1's are needed.
if you want to know more see
http://jakarta.apache.org/site/guidelines.html
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] New feature: Close method for Objects
Posted by Henri Yandell <ba...@generationjava.com>.
> The idea is simply to free the developer from the try/catch
> ignored-exception construct (which usually occurs when calling close()).
> If the developer were interested in dealing with the ignored exception
> in a meaningful way, this method wouldn't be appropriate.
Yeah, the decisions that need to be made are where this code would live,
and whether hiding exceptions is something that wants to be done. Normally
it's very frowned upon. But a low level code library can't be dependent on
a logging api.
> Also, I am new to all of this, could someone please explain this +1, -1
> stuff :)
+1 = I'm in favour of this and will help.
+0 = I'm in favour of this, but lack time to help.
-0 = I'm against this, but don't consider myself to be blocking it.
-1 = I'm against this and am blocking this happening.
When something is voted on, 3 +1 and no -1's are needed.
I'm probably a bit off there, different projects having different rules
etc, but it's around about the right ideas. Even when things aren't being
voted on, people tend to summarise their view on a subject with a + or -
1. The +-0 is mainly used for the official votes.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] New feature: Close method for Objects
Posted by Rand McNeely <ra...@yahoo.com>.
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Sunday, June 30, 2002 7:49 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] New feature: Close method for Objects
>
>
>
> On Sun, 30 Jun 2002, Stephen Colebourne wrote:
>
> > I would suggest that IO is a better home for the close method.
> >
> > Also, I would definitely not want Lang to have Logging.
> >
> > Stephen
>
> +1 on the -1 for Logging dependency. Which leaves either a silent Lang
or
> System.err. System.err always irritates me from a standard library,
but
> utter silence is a pain too.
>
> Oh, another option would be converting Exceptions to RuntimeExceptions
> when thrown.
>
> Any preferences?
>
> Hen
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
The idea is simply to free the developer from the try/catch
ignored-exception construct (which usually occurs when calling close()).
If the developer were interested in dealing with the ignored exception
in a meaningful way, this method wouldn't be appropriate.
Also, I am new to all of this, could someone please explain this +1, -1
stuff :)
Rand
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] New feature: Close method for Objects
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 30 Jun 2002, Stephen Colebourne wrote:
> I would suggest that IO is a better home for the close method.
>
> Also, I would definitely not want Lang to have Logging.
>
> Stephen
+1 on the -1 for Logging dependency. Which leaves either a silent Lang or
System.err. System.err always irritates me from a standard library, but
utter silence is a pain too.
Oh, another option would be converting Exceptions to RuntimeExceptions
when thrown.
Any preferences?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] New feature: Close method for Objects
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I would suggest that IO is a better home for the close method.
Also, I would definitely not want Lang to have Logging.
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 30, 2002 10:44 PM
Subject: Re: [lang] New feature: Close method for Objects
> My only worry with this one is logging.
>
> When errors occur in lang, and Exceptions are being supressed, what form
> of logging should occur? Or do we just make them quiet.
>
> Lastly, what performance drop do you see from using the reflection here?
> I'll assume you're caching the Method objects, so performance shouldn't be
> that big an issue.
>
> Hen
>
> On Sun, 30 Jun 2002, Rand McNeely wrote:
>
> > I've attached a close method for Objects. It uses reflection to call
> > close on the object passed to it and returns any exceptions (without
> > throwing them). I have found this to be very useful as most classes
> > which have a close method declare to throw an exception that can't be
> > dealt with in a meaningful way (java.io.InputStream,
> > java.sql.Connection, etc). This leads to constructs like this:
> >
> > finally {
> > try {
> > if (statement != null) {
> > statement.close();
> > }
> > } catch (SQLException ignored) {
> > }
> > try {
> > if (connection != null) {
> > connection.close();
> > }
> > } catch (SQLException ignored) { }
> > }
> > }
> >
> > which would be much cleaner like this:
> >
> > finally {
> > Objects.close(statement);
> > Objects.close(connection);
> > }
> >
> > Rand McNeely
> >
>
>
> --
> 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] New feature: Close method for Objects
Posted by Henri Yandell <ba...@generationjava.com>.
My only worry with this one is logging.
When errors occur in lang, and Exceptions are being supressed, what form
of logging should occur? Or do we just make them quiet.
Lastly, what performance drop do you see from using the reflection here?
I'll assume you're caching the Method objects, so performance shouldn't be
that big an issue.
Hen
On Sun, 30 Jun 2002, Rand McNeely wrote:
> I've attached a close method for Objects. It uses reflection to call
> close on the object passed to it and returns any exceptions (without
> throwing them). I have found this to be very useful as most classes
> which have a close method declare to throw an exception that can't be
> dealt with in a meaningful way (java.io.InputStream,
> java.sql.Connection, etc). This leads to constructs like this:
>
> finally {
> try {
> if (statement != null) {
> statement.close();
> }
> } catch (SQLException ignored) {
> }
> try {
> if (connection != null) {
> connection.close();
> }
> } catch (SQLException ignored) { }
> }
> }
>
> which would be much cleaner like this:
>
> finally {
> Objects.close(statement);
> Objects.close(connection);
> }
>
> Rand McNeely
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang] New feature: Close method for Objects
Posted by Rand McNeely <ra...@yahoo.com>.
I've attached a close method for Objects. It uses reflection to call
close on the object passed to it and returns any exceptions (without
throwing them). I have found this to be very useful as most classes
which have a close method declare to throw an exception that can't be
dealt with in a meaningful way (java.io.InputStream,
java.sql.Connection, etc). This leads to constructs like this:
finally {
try {
if (statement != null) {
statement.close();
}
} catch (SQLException ignored) {
}
try {
if (connection != null) {
connection.close();
}
} catch (SQLException ignored) { }
}
}
which would be much cleaner like this:
finally {
Objects.close(statement);
Objects.close(connection);
}
Rand McNeely
Re: [lang] is there a release on the visible horizon?
Posted by Henri Yandell <ba...@generationjava.com>.
This is an important point. We have two VOTEs to do.
Vote on moving into commons and then vote on releasing 1.0.
So the following ordering:
0) Make one set of changes.
1) Vote/Move commons-sandbox/lang to commons/lang.
2) Make second set of changes. Including reflection code into lang if
decided upon.
3) Vote/Release commons-lang 1.0.
On Sun, 30 Jun 2002, robert burrell donkin wrote:
> On Sunday, June 30, 2002, at 02:00 PM, Stephen Colebourne wrote:
>
> are you going to try for promotion to the commons before the release?
>
> it'd be a lot easier to move the reflection code into lang if lang were
> already a commons component.
>
> - robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] is there a release on the visible horizon?
Posted by robert burrell donkin <ro...@mac.com>.
On Sunday, June 30, 2002, at 02:00 PM, Stephen Colebourne wrote:
> From: "Henri Yandell" <ba...@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.
<snip>
> 4) add low level reflection code in reflect subpackage as was discussed a
> few weeks ago. (needs further discussion)
(FYI there is (at least) one fix which needs to be made to the reflection
code in beanutils.)
IMHO there isn't really any point holding up the initial release to get
this in.
are you going to try for promotion to the commons before the release?
it'd be a lot easier to move the reflection code into lang if lang were
already a commons component.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] is there a release on the visible horizon?
Posted by Steven Caswell <st...@caswell.name>.
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" <ba...@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: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] is there a release on the visible horizon?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang] release plans
Posted by Henri Yandell <ba...@generationjava.com>.
Going over the lists from the last week and trying to identify what is
done and what is not yet. Am sure more things will become apparant.
-------------------------------------------------------------------------
1) rename method in Objects
- change isNull() to defaultIfNull()
[DONE]
2) add hashCode building methods to Objects, or its own class based on
best hashCode practice. See [Lang] Add hashcode generating methods from
Stephen Colebourne.
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) Avalon system utilities. Not in initial Lang release.
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)
Remove Constant. Consider adding an Enum sub-package.
10) Strings - some methods are very specific (too specific) and could be
removed
i)
- parseObjectKey
- removeUnderscores
- reverseDottedName, reverseDelimitedString will do this so is dot a valid
special case
- interpolate - this seems to be very specific to a particular syntax
[DONE scolebourne]
ii)
Some methods have misleading names
- isValid() - should be isNotEmpty(), a not empty string is not
necessarily valid
[DONE scolebourne]
iii)
Some methods could be optimised:
- capitalise
- uncapitalise
- overlayString
[DONE rmcneely]
iv)
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
v)
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)
[Random: DONE - scolebourne]
vi)
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
[DONE - scolebourne]
11) Apply the patch to the NestedException classes.
12)
Create website. XDoc or generate by a tool such as Maven.
[Maven exammple:
http://www.generationjava.com/maven/jakarta-commons-sandbox/lang/
]
13) Unit Tests. More unit tests are needed. Numbers, Classes, Constant
need unit tests and Strings could do with more tests in its unit test.
14) Check Commons.Lang is in whichever bug tool is in use currently,
scarab or bugzilla.
15) Check what Commons.Lang/Gump status is.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] is there a release on the visible horizon?
Posted by Henri Yandell <ba...@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.
*) Apply your patch to the NestedException classes.
*) Website. I've the website that a recent version of Maven generates. Is
this usable or do we want to hand write something, or xdoc it anyway.
http://www.generationjava.com/maven/jakarta-commons-sandbox/lang/
Peruse the javadoc to find anything with bad javadoc. See if any of the
checkstyle errors are considered important, or just me not tuning it
correctly. Add other developers beyond the initial committers.
I've a document I wrote on a version of Strings for a JUG which I can
modify and attach to the site under some form of heading.
*) Unit Tests. More unit tests are needed. Numbers, Classes, Constant need
unit tests and Strings could do with more tests in its unit test. I won't
be able to start til Wednesday, but will make these my number one Apache
topic.
*) Check Commons.Lang is in whichever bug tool is in use currently, scarab
or bugzilla.
*) Check what Commons.Lang/Gump status is.
With those done, I think there should be nothing to stop a 1.0 version
being released, and we can call for a vote.
Any other things we need to do?
Hen
On Wed, 26 Jun 2002, Steven Caswell wrote:
> Is there a release on the visible horizon? I'd especially like to get
> the Nestable exception package available.
>
>
> Steven Caswell
> steven@caswell.name
>
>
>
> --
> 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>