parseInt and implicit octal constants

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Feb 24 08:43:22 PST 2009


James Graham wrote:
> David-Sarah Hopwood wrote:
>> Allen Wirfs-Brock wrote:
>>> Finally, there is another approach to resolving this issue.  Define a
>>> new global function, parseInteger, that does the "right thing" and
>>> relegate parseInt to Annex B.
>>
>> That's not a bad idea, given that parseInt has the additional flaw of
>> silently stopping at the first invalid character, which this change
>> will not fix. But it should be a "static" method of Number, not a global,
>> to avoid further polluting the global namespace and potentially clashing
>> with existing user functions.
> 
> It seems like having two functions with the same usecase but subtly
> different semantics contributes significantly to the cognitive burden of
> learning the language, and of reading other people's code, without — at
> least in this case — providing a huge number of clear cut benefits.

Reporting an error when there are invalid characters in the string, rather
than silently returning the wrong value in that case, is a clear-cut
benefit.

parseInt is not particularly useful to programmers who actually care about
input validation. (If you validate that a string represents a decimal
integer first, then you could just as well use 'Number(s)' or '+s' to
convert it to a number.)

-- 
David-Sarah Hopwood ⚥



More information about the Es-discuss mailing list