Fun with Number readFrom: What should we do ?

Andreas Raab andreas.raab at gmx.de
Thu Apr 27 23:45:50 UTC 2006


Francisco Garau wrote:
 > This would be both flexible and generic.

And complete and utter overkill in my understanding ;-) Yes, of course, 
you can do what you just described but by the end of the day, there are 
two prevalent use cases: 1) I want to read a "Squeak number", e.g., I 
want to read whatever is considered a valid numeric literal in Squeak. 
2) I want to read "something else" and it doesn't matter whether that 
"something else" is a roman number, a scientific one, a .csv data 
record. What does matter is that Squeak cannot possibly provide parsers 
for all numeric formats ever in existence, and neither should it. What 
it should do is to read its own literals correctly and quickly.

Therefore (coming back to the starting point of this discussion) for 
Number/Integer/Float>>readFrom: (which by definition are within use case 
1) we should not overly generalize reading numbers to the point where 
it's both slow and gets nothing quite right (since there are almost 
certainly ambiguous representations). What we should do is to fix what 
is broken and nothing more; namely that reading a number from an empty 
string answers zero.

And if you feel that you need more flexibility and format support than 
Squeak currently provides, feel free to set up a Numeric Parser project 
on SqueakSource and put that parser there fore anyone to use who needs 
it. This leaves plenty of room for experimentation (like substituting 
Number>>readFrom: in the way you are suggesting) and doesn't get into 
the way of fixing the bug that started the whole discussion.

Cheers,
   - Andreas

Francisco Garau wrote:
> I totally agree with Diego.
> 
> Moreover, I think that each message should do the parsing on exactly one 
> format. Something like this:
> 
>    (SqNumberParser on: '1.23') number
>    (SqNumberParser on: '1.23e4) scientificNotation; number
>    (SqNumberParser on: '2r1111') base2Notation; number
>    (SqNumberParser on: '') cvsNotation; number "would answer 0"
> 
> And then we can add a top level method to try several alternatives (in a 
> specific order)
> 
>    SqNumberParser>>parse
>        try scientificNotation ifTrue: [^got it]
>        try xxxNotation ifTrue: [^got it]
>        try base2Notation ifTrue: [^got it]
>        try base16Notation ifTrue: [^got it]
>        else ParseException signal
> 
> This would be both flexible and generic. Those who know precisely the 
> string format of an expected number, can use the specific parse message. 
> And if you don't know the string format, just use the generic parse 
> message.
> 
> String>>sqNumber
>    ^(SqNumberParser on: self) parse; number
> 
> By using the Sq prefix, we would avoid clashing with existing methods. 
> The code that is relying on the current funny behaviour would remain 
> unaffected.
> 
> Cheers,
> Francisco
> 
> 
> ----- Original Message ----- From: "Diego Fernandez" <diegof79 at gmail.com>
> To: <ncellier at ifrance.com>; "The general-purpose Squeak developers list" 
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Thursday, April 27, 2006 2:59 PM
> Subject: Re: Fun with Number readFrom: What should we do ?
> 
> 
>> My proposition is:
>>
>> Number>>readFrom: aStringOrStream
>>     ^self readFrom: aStringOrStream ifFail: [^self error: 'cannot read a
>> number']
>>
>> If nil is what you want, you will have to write:
>>     value := Number readFrom: aStream ifFail: [nil].
>> A little longer than your proposition:
>>     value := Number readfrom: aStream.
> 
> The mine is:
> Number>>readFrom: aStringOrStream
>      ^NumberParser new parse: aStringOrStream
> 
> NumberParser>>parse: aStringOrStream
>       "on failure"
>        NumberParsingException signal
>        "or just ParseException"
> 
> I think that #readFrom: must be an extension of Number.
> So if you want more control of the parsing you can configure an
> instance of NumberParser.
> (may be you can have a FortranNumberParser :)).
> 
> 
> 




More information about the Squeak-dev mailing list