Hi,
the parseInt/parseLong API was changed[1] in accordance with the
discussion in this thread. That
big shuffling around of modules also happened, so I've updated this patch:
http://cr.openjdk.java.net/~redestad/8055032/webrev.1/
/Claes
[1] https://bugs.openjdk.java.net/browse/JDK-8055251
On 14/08/2014 14:39, Alan Bateman wrote:
On 14/08/2014 14:23, Claes Redestad wrote:
How about methods only taking beginIndex? Integer.parseInt("x:
1000", 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 ther
On 08/14/2014 02:00 PM, 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
parame
On 14/08/2014 14:23, Claes Redestad wrote:
How about methods only taking beginIndex? Integer.parseInt("x:
1000", 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 impl
How about methods only taking beginIndex? Integer.parseInt("x:
1000", 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(CharSequenc
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 par
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 imple
On 08/14/2014 01:30 PM, Alan Bateman wrote:
On 14/08/2014 10:32, Claes Redestad wrote:
:
Any particular place where you think readability becomes a problem?
I've grown fond of the
parseInt(s, radix, offset) form myself, but I'm biased. ;-)
It's somewhat subjective but when a method has a sequ
On 14/08/2014 10:32, Claes Redestad wrote:
:
Any particular place where you think readability becomes a problem?
I've grown fond of the
parseInt(s, radix, offset) form myself, but I'm biased. ;-)
It's somewhat subjective but when a method has a sequence of parameters
that are the same type (i
On 08/14/2014 09:37 AM, Alan Bateman wrote:
On 13/08/2014 15:02, Claes Redestad wrote:
Hi,
can I have a review for this patch to take advantage of offset-based
parseInt methods added in
8041972 for java.net/sun.net classes?
bug: https://bugs.openjdk.java.net/browse/JDK-8055032
webrev: http:/
On 13/08/2014 15:02, Claes Redestad wrote:
Hi,
can I have a review for this patch to take advantage of offset-based
parseInt methods added in
8041972 for java.net/sun.net classes?
bug: https://bugs.openjdk.java.net/browse/JDK-8055032
webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev
Hi,
can I have a review for this patch to take advantage of offset-based
parseInt methods added in
8041972 for java.net/sun.net classes?
bug: https://bugs.openjdk.java.net/browse/JDK-8055032
webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev.0
This causes fewer temporary String objec
12 matches
Mail list logo
