parseInt and implicit octal constants

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sun Feb 22 14:00:18 PST 2009


Allen Wirfs-Brock wrote:
> David-Sarah Hopwood wrote:
>> Herman Venter wrote:
>>> I appreciate that this proposal does not try to go all the way on
>>> octal. I am not so sure this is a good thing or that it makes the
>>> proposal more likely to succeed.
>>
>> I wouldn't be opposed to removing octal entirely from the spec, but
>> bearing in mind the section 16 wording on syntactic extensions, even
>> that would not prevent implementors from conformantly supporting it.
> 
> Actually, I don't think section 16 applies.

It doesn't apply to parseInt; it does to octal numeric literals and
string/regexp octal escapes (which "going all the way on octal" would
remove from the spec).

[...]
> 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.

-- 
David-Sarah Hopwood ⚥




More information about the Es-discuss mailing list