Fun with Number readFrom: What should we do ?
Martin Wirblat
sql.mawi at t-link.de
Fri Apr 28 09:55:27 UTC 2006
Andreas Raab wrote:
> The example of the csv file is very badly chosen IMO. CSV files contain
> many different things and applying the same logic you are using for
> numbers here would dictate that String>>readFrom: also answer nil when
> trying to read from an empty string. Moreover, it would dictate that
> Strings use double quotes (if I remember my .csv corretly). This has
> nothing to do with the discussion here - .csv files do NOT contain
> "Smalltalk numbers" so to speak, therefore they need to be separately
> parsed and analyzed and arguing that an empty string should parse as nil
> because .csv files have empty fields is really besides the point of this
> discussion.
>
I want to parse 1.23 and that is not a Smalltalk number, it is a number.
If I read '' from a csv file, from a user input or a free-form text as
what could or should be a number, the data point is undefined, and nil
is expressing that literally.
> Number>>readFrom: has the specific intent to read a literal number from
> a stream. I have yet to find a caller that could even deal with the fact
> that this method may answer nil. This goes mostly to show at what a low
> level number parsing is typically used (e.g., all the error checking
> happens mostly at a higher level) which speaks very clearly for having
> an exception raised to signal the problem.
>
There is no problem or error unless you define that Number>>readFrom:
has to be and can only be used when Squeak had written a "Smalltalk
number" out and now has to get it back.
> @Nicolas: I find your proposal of readFrom:ifFail: to be somewhat
> overkill. An exception/error seems simpler and more direct to me.
>
Prohibiting overkill solutions was the pragmatical point of my suggestion.
Regards,
Martin
More information about the Squeak-dev
mailing list
|