Re: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

2014-09-10 Thread Claes Redestad
On 09/05/2014 03:49 PM, Alan Bateman wrote: On 05/09/2014 14:03, Claes Redestad wrote: Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251

Re: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

2014-09-10 Thread Remi Forax
On 09/10/2014 01:55 PM, Claes Redestad wrote: On 09/05/2014 03:49 PM, Alan Bateman wrote: On 05/09/2014 14:03, Claes Redestad wrote: Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug:

[9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

2014-09-05 Thread Claes Redestad
Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251 webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/

Re: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

2014-09-05 Thread Alan Bateman
On 05/09/2014 14:03, Claes Redestad wrote: Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251 webrev:

Re: Integer.parseInt

2012-04-12 Thread Benedict Elliott Smith
Remi and I have in the past had differences of opinion on the utility of introducing CharSequence versions of such methods. One benefit to using a string is that the object is immutable; there are no time-of-check-versus-time-of-**use conditions to worry about. Robust code should arguably

Re: Integer.parseInt

2012-04-12 Thread Martin Desruisseaux
Le 12/04/12 10:57, Benedict Elliott Smith a écrit : I think in this case it is reasonable to leave it to the user to ensure that the input remains consistent for the duration of the call. It can be documented if necessary, but as I say I think all imperative methods come with that caveat by

Re: Integer.parseInt

2012-04-12 Thread Ulf Zibis
+1 to Benedict and Martin -Ulf Am 12.04.2012 11:35, schrieb Martin Desruisseaux: Le 12/04/12 10:57, Benedict Elliott Smith a écrit : I think in this case it is reasonable to leave it to the user to ensure that the input remains consistent for the duration of the call. It can be documented if

Integer.parseInt

2012-04-11 Thread Benedict Elliott Smith
Hi, Looking at the source code, it doesn't appear as though there is any reason to require the input be a String - only length() and charAt() are called, which are both declared by CharSequence. Is there a reason I can't fathom, or was it an oversight? It would be nice to widen the type for this

Re: Integer.parseInt

2012-04-11 Thread Benedict Elliott Smith
can't fathom, or was it an oversight? It would be nice to widen the type for this (and potentially other equivalent methods). Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4), that's why it use a String an not a CharSequence. If you don't want to break all already compiled programs

Re: Integer.parseInt

2012-04-11 Thread Joe Darcy
. Is there a reason I can't fathom, or was it an oversight? It would be nice to widen the type for this (and potentially other equivalent methods). Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4), that's why it use a String an not a CharSequence. If you don't want to break all already