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