parseInt and implicit octal constants
jgraham at opera.com
Mon Feb 23 07:38:50 PST 2009
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.
It seems like standardizing something that is theoretically nicer
without any clear promise that implementations will converge on that
behavior is not doing users any favours since they will still not be
able to predict the behaviour of implementations they have not tested,
rendering the specification pointless. That suggests to me that
specifying the de-facto standard set by Microsoft/Mozilla/Apple here is
the right way forward.
More information about the Es-discuss