Hacker News Reader

Comment by oscargrouch | Hacker News Reader

with a function named "parseInt" anyone would expect the inputs as base 10.. otherwise this shoud be called "parseHex" for 15 or at least "parseBytes(input, base)"

The programmers are not the ones to blame on that.. this is really a bad contract between the language and the programmer

Its the equivalent of a function named "getStone()" to return you a " Paper{} " :)

View on HN

"int" doesn't imply anything about the base.

It does for human beings. We use base-10 for basically everything. This is true even for most programmers in most situations. Human beings aren't computers, and we aren't abstract math processing units who by default consider numbers abstracted (e.g. as elements of Rings). This goes double for string representations of numbers--in the majority of cases a number represented by a string is a number meant for human consumption in a normal human context; not some machine running in base-2 (or -8 or -16). It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default, and entirely unreasonable to expect to be required to provide a base as anything except an optional argument, and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation.

> It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default

It does.

> and entirely unreasonable to expect to be required to provide a base as anything except an optional argument

It is optional.

> and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation

I don't understand what you're saying here. It's never treated as required, it's just map supplies a parameter in that position, so it get's used. That's how optional parameters work.

The wat (if there is one) is that map provides extra arguments.

>> ...parse an integer out of a string in base-10 by default

> It does.

Not quite: in some browsers (IE), a string starting with '0' gets interpreted as octal. So parseInt('041') === 33 in IE.

Guess how I found out about that.

I agree with your conclusions. However, the poster I was responding to was suggesting that the category of "int" necessarily excludes non-decimal representations in the same sense that the category of "stone" excludes "paper".

I think in this case it's not parseInt that's at fault, it's the fact that map optionally passes additional arguments.

Reply on news.ycombinator.com