RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

[Claes Redestad]

How about methods only taking beginIndex? Integer.parseInt("x: 
10000000", 3, 10)? I guess these could to be dropped
to avoid ambiguity and instead allow for variations where radix can be 
left out.

I think there are two alternatives to the current implementation:
- only keep parseInt(CharSequence s, int beginIndex, int endIndex, int 
radix)
- optional radix: parseInt(CharSequence s, int beginIndex, int 
endIndex), parseInt(CharSequence s, int beginIndex, int endIndex, int radix)

(Should this discussion be moved to core-libs-dev?)

/Claes

On 08/14/2014 03:15 PM, roger riggs wrote:
> Hi,
>
> My preference would be to keep the offsets immediately following the 
> CharSequence,
> that clearly identifies the substring being operated on.
>
> Roger
>
>
> On 8/14/2014 8:00 AM, Alan Bateman wrote:
>> On 14/08/2014 12:42, Claes Redestad wrote:
>>>
>>> Noone brought it up, as far as I can recall. Since parseInt(String, 
>>> int radix) already existed, I figured adding the range parameters to 
>>> the end would be overall less awkward than to push the radix 
>>> parameter right in the new methods. The chosen implementation 
>>> maintains that the second parameter is always radix, which I think 
>>> helps maintain consistency.
>> I think consistency could be argued both ways as the radix is also 
>> the last parameter in the existing methods. When I look at this method:
>>
>> public static int parseInt(CharSequence s, int radix, int beginIndex, 
>> int endIndex)
>>
>> and then feels more error prone than if the beginIndex/endIndex were 
>> immediately after the CharSequence.
>>
>> I'm interested in other opinions on this.
>>
>> -Alan.
>