Actually I think this is an inconsistency in the API we should resolve. My proposal is to:
deprecate Int.isDigit
add Int.isNum
add Str.isNum
That makes Int/Str uniform (since Str.isDigit doesn't work), and also consistent with isAlphaNum which both classes already have.
Any objections?
jodastephenMon 2 Aug 2010
Sounds good
katoxMon 2 Aug 2010
+1
tacticsMon 2 Aug 2010
Any objections?
Only that Int.isNum is really confusing if you're looking through the docs.
jodastephenMon 2 Aug 2010
Good point on Int.isNum.
More generally, on rereading the docs, I've found the merge of Int and Char to be confusing in general. I wonder if it would be better to separate the concepts in the API? Personally, I think of them as quite distinct.
brianMon 2 Aug 2010
Actually maybe Str.isDigits might be better match for Int.isDigit since Num implies a base class for Int, Float, or Decimal.
rfeldmanMon 2 Aug 2010
I would wonder if Str.isDigits would return true for "123.45" since "." is not a digit.
brian Mon 2 Aug 2010
From #1165
Actually I think this is an inconsistency in the API we should resolve. My proposal is to:
Int.isDigit
Int.isNum
Str.isNum
That makes Int/Str uniform (since Str.isDigit doesn't work), and also consistent with isAlphaNum which both classes already have.
Any objections?
jodastephen Mon 2 Aug 2010
Sounds good
katox Mon 2 Aug 2010
+1
tactics Mon 2 Aug 2010
Only that
Int.isNum
is really confusing if you're looking through the docs.jodastephen Mon 2 Aug 2010
Good point on
Int.isNum
.More generally, on rereading the docs, I've found the merge of Int and Char to be confusing in general. I wonder if it would be better to separate the concepts in the API? Personally, I think of them as quite distinct.
brian Mon 2 Aug 2010
Actually maybe Str.isDigits might be better match for Int.isDigit since Num implies a base class for Int, Float, or Decimal.
rfeldman Mon 2 Aug 2010
I would wonder if Str.isDigits would return true for "123.45" since "." is not a digit.
Personally I like Str.isNum and Int.isDigit