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.
