Tim Rowledge <tim at sumeru.stanford.edu> wrote:

> I'd say that somewhere in the sequence of messages the debugger will
> show you should be removing/skipping leading non-digits. It looks a
> little extra complicated since I imagine leading non-digits in a radix'd
> number would be improper (ie '16r 23' may well be improper, depending on
> definitions I don't know the details of).
> 
> Lex, this method has your initials attached, so maybe you know the
> gestalt of what is intended?


Errr uhhhh.  1999 huh...  Oh!  My edit, if I remember correctly, was
just to allow a $+ at the beginning of the string.  I didn't touch the
rest of the method.

It looks like there is an explicit check for having at least one digit, which
I agree is odd considering the comment on the class!

Why isn't this an error, however?  It is very easy to make the mistake
of passing in an empty string or a string with only spaces to #asNumber, when
you ment to send in some other string.  Reporting an error would be helpful in
this common case.  To contrast,  how often is it convenient to intersperse
things like 'abcd' with things like '1234' ?

Dynamic typing *without* actual type checks can become a nightmare.  I've
heard vague horror stories from the Python world about this, and I've heard
a specific problem in the Visual Basic world about this, where certain input
routines will sometimes return numbers and sometimes strings.  Dynamic typing
doesn't mean anarchy.


I *can* sorta see a use for '' mapping to 0, just because this is such
a logical interpretation.  'abcd' mapping to 0 doesn't seem so useful.
',12,13' mapping to 0 *sort* of does, but that would seem better handled
by tokenizing and *then* doing the asNumber, anyway.

So in short, I would vote for fixing the comment.  :)  

Incidentally, ANSI seems to be quiet in my quick scan.  I don't see any obvious
methods for converting '123' to 123 .


Lex