parseInt and implicit octal constants
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