[lang] [patch] Conversion of String to long/double

[Fredrik Westermarck <fr...@mdh.se>]

Hi!

Here is the patch that adds stringToLong(String str), 
stringToLong(String str, long), stringToDouble(String str) and 
stringToDouble(String str, double), testcases are also included.

I have also improved the testcase for stringToFloat(String).

Hopefully I managed to get the diff right. I had to remove several lines 
by hand because of differences in the indentation (space vs tabs?). Is 
there any document that describes what codestyle commons-lang is 
supposed to use?

Re: [lang] [patch] Conversion of String to long/double

[Fredrik Westermarck <fr...@mdh.se>]

Stephen Colebourne wrote:

> Do we feel that the stringToInt() naming is good for these methods?
> 
> BooleanUtils uses toBoolean(), which is shorter and fits better with JDK
> standards. Thus
> toInt(String)
> toLong(String)
> etc.
> 
> Opinions?

I agree that the to<Type> methodname is better.

Re: [lang] [patch] Conversion of String to long/double

[Stephen Colebourne <sc...@btopenworld.com>]

Certainly a deprecation would be required, if this is what we agree on. I'm
+1 to the change.

Stephen

----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, September 06, 2003 6:44 PM
Subject: Re: [lang] [patch] Conversion of String to long/double


> Stephen Colebourne wrote:
> > Do we feel that the stringToInt() naming is good for these methods?
> >
> > BooleanUtils uses toBoolean(), which is shorter and fits better with JDK
> > standards. Thus
> > toInt(String)
> > toLong(String)
> > etc.
> >
> > Opinions?
> >
> > Stephen
>
>
> I agree that the short names are a bit better, though I don't see this
> as a big deal and we should keep in mind that stringToInt was released
> as part of 2.0.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

Re: [lang] [patch] Conversion of String to long/double

[Phil Steitz <ph...@steitz.com>]

Stephen Colebourne wrote:
> Do we feel that the stringToInt() naming is good for these methods?
> 
> BooleanUtils uses toBoolean(), which is shorter and fits better with JDK
> standards. Thus
> toInt(String)
> toLong(String)
> etc.
> 
> Opinions?
> 
> Stephen


I agree that the short names are a bit better, though I don't see this 
as a big deal and we should keep in mind that stringToInt was released 
as part of 2.0.

Phil

Re[2]: [lang] [patch] Conversion of String to long/double

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Stephen!

SC> Do we feel that the stringToInt() naming is good for these methods?

SC> BooleanUtils uses toBoolean(), which is shorter and fits better with JDK
SC> standards. Thus
SC> toInt(String)
SC> toLong(String)
SC> etc.

SC> Opinions?

<outsider>

    Will really be a nice move :)

    You guys do show us (not commons-lang developers)
    how to code, short names rock!
    
</outsider>

-Anton

Re: [lang] [patch] Conversion of String to long/double

[Stephen Colebourne <sc...@btopenworld.com>]

Do we feel that the stringToInt() naming is good for these methods?

BooleanUtils uses toBoolean(), which is shorter and fits better with JDK
standards. Thus
toInt(String)
toLong(String)
etc.

Opinions?

Stephen

----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, September 05, 2003 5:01 PM
Subject: Re: [lang] [patch] Conversion of String to long/double


> Fredrik Westermarck wrote:
> > Hi!
> >
> > Here is the patch that adds stringToLong(String str),
> > stringToLong(String str, long), stringToDouble(String str) and
> > stringToDouble(String str, double), testcases are also included.
> >
> > I have also improved the testcase for stringToFloat(String).
>
> Patch committed. Thanks!
> Phil
>
> >
> > Hopefully I managed to get the diff right. I had to remove several lines
> > by hand because of differences in the indentation (space vs tabs?). Is
> > there any document that describes what codestyle commons-lang is
> > supposed to use?
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

Re: [lang] [patch] Conversion of String to long/double

[Phil Steitz <ph...@steitz.com>]

Fredrik Westermarck wrote:
> Hi!
> 
> Here is the patch that adds stringToLong(String str), 
> stringToLong(String str, long), stringToDouble(String str) and 
> stringToDouble(String str, double), testcases are also included.
> 
> I have also improved the testcase for stringToFloat(String).

Patch committed. Thanks!
Phil

> 
> Hopefully I managed to get the diff right. I had to remove several lines 
> by hand because of differences in the indentation (space vs tabs?). Is 
> there any document that describes what codestyle commons-lang is 
> supposed to use?
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] [patch] Conversion of String to long/double

[Phil Steitz <ph...@steitz.com>]

Henri Yandell wrote:
> 
> On Thu, 4 Sep 2003, Fredrik Westermarck wrote:
> 
> 
>>Hopefully I managed to get the diff right. I had to remove several lines
>>by hand because of differences in the indentation (space vs tabs?). Is
>>there any document that describes what codestyle commons-lang is
>>supposed to use?

In general, follow Hen's sage advice below.  If you are finding tabs in 
the source, however, these should be eliminated.  If you run maven 
site:generate, the checkstyle plugin should flag this.  It is also 
always a good idea to run either maven or ant clean dist and review the 
javadoc report to make sure that all tests run and the patch is not 
introducing any javadoc warnings or errors.

Thanks for the patches!

Phil

> 
> 
> In the long term, a maven site and checkstyle might enforce this, but in
> real terms the codestyle to use is the same as the nearest neighbour.
> 
> So if you're adding a method to NumberUtils, follow the style of
> NumberUtils. If you're adding a new class to lang.time, follow the style
> of a core class in lang.time. If you're adding a new package, you should
> have a good general feel for the style already :)
> 
> Basic rules of working on a community codebase I guess.
> 
> There are some basic concepts in the DESIGN-GUIDE file which state how
> XxxUtils classes should be, and there is a checkstyle.xml in there, if you
> know how to read that.
> 
> Hen
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

[Fredrik Westermarck <fr...@mdh.se>]

Phil Steitz wrote:
>>> Strangely, the checkstyle plugin is not complaining about any tabs in 
>>> the code.  Are you finding these in the tests or in the /java sources?
>> The differences is mainly in lines that are blank.
>> In the cvs these lines contains 6 whitespace chars and there are no 
>> whitespaces in my local files. These differences are present both in 
>> NumberUtils and in NumberUtilsTest.
> Did you update after the first commit?  I did remove one blank line and 
> added braces around an if() construct before committing the first patch. 
>  I noticed that the missing braces were present in the second patch.

Yes, I did make an cvs update after the first commit.

Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

[Phil Steitz <ph...@steitz.com>]

Fredrik Westermarck wrote:
> Phil Steitz wrote:
> 
>> Strangely, the checkstyle plugin is not complaining about any tabs in 
>> the code.  Are you finding these in the tests or in the /java sources?
> 
> 
> The differences is mainly in lines that are blank.
> 
> In the cvs these lines contains 6 whitespace chars and there are no 
> whitespaces in my local files. These differences are present both in 
> NumberUtils and in NumberUtilsTest.
> 
> 
Did you update after the first commit?  I did remove one blank line and 
added braces around an if() construct before committing the first patch. 
  I noticed that the missing braces were present in the second patch.

Phil

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

[Fredrik Westermarck <fr...@mdh.se>]

Phil Steitz wrote:

> Strangely, the 
> checkstyle plugin is not complaining about any tabs in the code.  Are 
> you finding these in the tests or in the /java sources?

The differences is mainly in lines that are blank.

In the cvs these lines contains 6 whitespace chars and there are no 
whitespaces in my local files. These differences are present both in 
NumberUtils and in NumberUtilsTest.

Re: [lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

[Phil Steitz <ph...@steitz.com>]

Fredrik Westermarck wrote:
> Henri Yandell wrote:
> 
>>> Hopefully I managed to get the diff right. I had to remove several lines
>>> by hand because of differences in the indentation (space vs tabs?). Is
>>> there any document that describes what codestyle commons-lang is
>>> supposed to use?
>>
>>
>> In the long term, a maven site and checkstyle might enforce this, but in
>> real terms the codestyle to use is the same as the nearest neighbour.
> 
> 
> Since I haven't used maven yet, will it still be possible to build with 
> ant only?

The ant build still works fine.

> 
>> So if you're adding a method to NumberUtils, follow the style of
>> NumberUtils. If you're adding a new class to lang.time, follow the style
>> of a core class in lang.time. If you're adding a new package, you should
>> have a good general feel for the style already :)
> 
>  >
>  > Basic rules of working on a community codebase I guess.
> 
> I used the same codestyle this time as for my previous patch to 
> NumberUtils. When creating the diff for my previous patch I didn't have 
> any problem with the indentation so I guess that the codestyle for the 
> class changed when Phil commited it... :)

If it did, that was certainly not intentional.  Strangely, the 
checkstyle plugin is not complaining about any tabs in the code.  Are 
you finding these in the tests or in the /java sources?

> 
>> There are some basic concepts in the DESIGN-GUIDE file which state how
>> XxxUtils classes should be, and there is a checkstyle.xml in there, if 
>> you
>> know how to read that.
> 
> 
> No, I don't know how checkstyle.xml works, but it never too late to 
> learn... I'll have a look at them and try to create a codestyle for my IDE.

Just check out the docs here: http://checkstyle.sourceforge.net/

Phil

> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

[lang] Codestyle (Was: [lang] [patch] Conversion of String to long/double)

[Fredrik Westermarck <fr...@mdh.se>]

Henri Yandell wrote:

>>Hopefully I managed to get the diff right. I had to remove several lines
>>by hand because of differences in the indentation (space vs tabs?). Is
>>there any document that describes what codestyle commons-lang is
>>supposed to use?
> 
> In the long term, a maven site and checkstyle might enforce this, but in
> real terms the codestyle to use is the same as the nearest neighbour.

Since I haven't used maven yet, will it still be possible to build with 
ant only?

> So if you're adding a method to NumberUtils, follow the style of
> NumberUtils. If you're adding a new class to lang.time, follow the style
> of a core class in lang.time. If you're adding a new package, you should
> have a good general feel for the style already :)
 >
 > Basic rules of working on a community codebase I guess.

I used the same codestyle this time as for my previous patch to 
NumberUtils. When creating the diff for my previous patch I didn't have 
any problem with the indentation so I guess that the codestyle for the 
class changed when Phil commited it... :)

> There are some basic concepts in the DESIGN-GUIDE file which state how
> XxxUtils classes should be, and there is a checkstyle.xml in there, if you
> know how to read that.

No, I don't know how checkstyle.xml works, but it never too late to 
learn... I'll have a look at them and try to create a codestyle for my IDE.

Re: [lang] [patch] Conversion of String to long/double

[Henri Yandell <ba...@generationjava.com>]

On Thu, 4 Sep 2003, Fredrik Westermarck wrote:

> Hopefully I managed to get the diff right. I had to remove several lines
> by hand because of differences in the indentation (space vs tabs?). Is
> there any document that describes what codestyle commons-lang is
> supposed to use?

In the long term, a maven site and checkstyle might enforce this, but in
real terms the codestyle to use is the same as the nearest neighbour.

So if you're adding a method to NumberUtils, follow the style of
NumberUtils. If you're adding a new class to lang.time, follow the style
of a core class in lang.time. If you're adding a new package, you should
have a good general feel for the style already :)

Basic rules of working on a community codebase I guess.

There are some basic concepts in the DESIGN-GUIDE file which state how
XxxUtils classes should be, and there is a checkstyle.xml in there, if you
know how to read that.

Hen