5 ms·

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, bas

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{} " :)

djur 13y ago
"int" doesn't imply anything about the base.
- deleted 13y ago
  [deleted]
- Iftheshoefits 13y ago
  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.
  - ajanuary 13y ago
    > 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.
    - deleted 13y ago
      [deleted]
    - nollidge 13y ago
      >> ...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.
  - djur 13y ago
    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.

djur 13y ago

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

deleted 13y ago
[deleted]
Iftheshoefits 13y ago
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.
- ajanuary 13y ago
  > 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.
  - deleted 13y ago
    [deleted]
  - nollidge 13y ago
    >> ...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.
- djur 13y ago
  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.