Hi Damien,
I knew there was something strange sometime with number parsing: do you remember the thread "[BUG] nil ~= 1and: [1 isNil] is parsed+compiled without complaint".
That time it was decided, IIRC, that '1and' parses '1' then 'and' correctly.
So what can a sender of #readFrom: do
- a) decide that it will indeed send #readFrom: and - b) decide what to do if no digit is before the first nonDigit, nonMinus character.
One solution would be that (Number>>readFrom: 'and') returned nil, just to make it different from (Number>>readFrom: '0and').
OTOH the Scanner handles the case when Number>>readFrom: signals an error, why doesn't everybode else do so ;-)
/Klaus
On Wed, 21 Mar 2007 15:06:04 +0100, Damien Cassou wrote:
Nicolas told me that this bugs follows the bug: http://bugs.impara.de/squeak/view.php?id=3512
The aim of the test is to verify that an error is thrown instead of 0 which is a number and should not indicate an error. The only place where we will get an error is if the stream starts by $r which is stupid.
Number readFrom: 'a' => 0 Number readFrom: 'r' => ERROR
Nicolas proposes to replace Number>>readFrom: to use his parser (which is already in the image but not used by default: SqNumberParser). The only problem with its parser is the non backward compatible behavior on that problem.
So, what do we do?
squeak-dev@lists.squeakfoundation.org