Fun with Number readFrom: What should we do ?
stéphane ducasse
ducasse at iam.unibe.ch
Fri Apr 28 09:45:44 UTC 2006
+ 1
Stef
On 28 avr. 06, at 01:45, Andreas Raab wrote:
> 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
|