JRS: In article <
[email protected]>,
dated Mon, 28 Aug 2006 23:15:49 remote, seen in
news:comp.lang.javascript said:
That doesn't make sense - to me it reads "don't use parseInt because
it's faster and shorter than alternatives".
It should make perfect nonsense, as I was concentrating on clarity and
totally forgot to check what might be called the polarity of the
statement :-( .
Did you really mean:
"function parseInt should be used only when beneficial, as
it is longer or slower than alternatives."
Well, maybe ... "as alternatives are shorter and faster."
Probably not to most. Less condescending is:
"Bases 2..7, 9, 11..15, 17..36 require parseInt(S, B)."
But then someone like Randy will complain about 8 being missing, as
earlier in the thread. "... 17..36 clearly ..." ?
How about:
For converting a possibly signed base-B digit string, S, to a Number,
function parseInt should be used only when beneficial, as it is
longer or slower than alternatives. and
For values of numeric properties, given in decimal without a leading
zero and possibly followed by a unit (such as when getting the value
of a style property, e.g. 33px), parseInt(S) is appropriate.
Bases 2 to 7, 9, 11 to 15, 17 to 36 require parseInt(S, B) always.
Bases 8, 10 and 16, where S is a string of non-negative integer value
and non-numeric parts have been trimmed (e.g. 09kg has been trimmed
to 09), can be of the forms:
S B Conversion Note
0123 8 use parseInt(S, 8) 1
0123 10 unary + preferred 2
2345 10 unary + preferred 2
0x6b4 16 unary + preferred
6b4 16 use parseInt(S, 16)
Notes :
1: B is required for compatibility with ECMA 262 3rd Edn, and
for compatibility with all browsers.
2: Common when converting the value of form controls to Number.
Looks good.
It needs to be compared with the FAQ note
<li><a href=
"
http://www.jibbering.com/faq/faq_notes/type_convert.html#tcPrIntRx">
Javascript Type-Conversion - parseInt with a radix argument</a>
...
<FAQENTRY> 4.12 is
"The parseInt function decides what base the number is by looking at the
number. By convention it assumes any number beginning with 0 is Octal,
and any number beginning with 0x Hexadecimal. To force use of base 10
add a second parameter parseInt("09",10)"
and needs to be more like
"If no Base is given, the parseInt function decides what base the number
is in by looking at the number. It assumes that any number beginning
with 0x is Hexadecimal, and may assume that any number beginning with 0
is Octal. To force use of bases 8 or 10 add a second parameter, as in
parseInt("09", 10) or parseInt("077", 8).".
</FAQENTRY>
FAQ NOTES : type_convert
In table "Double NOT (!!col) : Other Values." and elsewhere, "return;"
serves no apparent purpose?
Just before heading "Converting to String", around "can avoid generating
errors" : IMHO it should note that, while no error will be raised by the
browser, an intention of the programmer may not be fulfilled and
alternative provision should be considered.
In "Converting to String", "the type-conversion mechanism is rarely
suited" - not so - not "rarely". It is suited to handling the results
of integer computation, and computation should be in integers where
practical (e.g. money).
In "Converting to Number", I would recommend, for safety and efficiency,
that the value of a numeric entry is generally converted to Number on
acquisition (rather than using repeated auto-conversion) :
Num = + form.control.value
or
Str = form.control.value
// Validate Str by RegExp
Num = + Str
"Strings that cannot be read as a number type-convert to NaN," - except
"Infinity", "+Infinity", "-Infinity" !
In "Parsing to Number", para 2 does not mention leading whitespace.
ISTM that it would be useful for each FAQ Note to contain a plaintext
date, altered at any significant change.
Something rather like our text above could be put into that section.
Inserted, with minor editing, in <URL:
http://www.merlyn.demon.co.uk/js-
maths.htm>.