Talk:Read

questionable claims

This Note: Therefore the main application of read or readLn is non-interactive programs reading (generated) data files. IMO that doesn;t make a lot of sense.
Also "Beware, it is necessary to check for end of file." That makes no sense to me in the context of the example program above, which clearly is only meant to read from input. --Bart (talk) 15:02, 25 May 2020 (CEST)

This sentence: "Nevertheless, if the convenient interpretation functionality is desired, without having a file open, the procedure system.readStr can be used to do so."

Also makes little sense in the context, quite apart from being difficult to parse. --Trev (talk) 03:29, 26 May 2020 (CEST)

Bart, I did insert that claim. Why doesn’t make reading (generated) data using read/readLn a lot of sense? Honestly, I wouldn’t use these procedures in a program I’d roll out to the average customer, you know. If I’m interfacing with some sort of API, let’s say reading data from the /proc or /sys directory trees, I’d use them since they’re pretty straightforward, but not for interactive input. Would you use read/readLn in serious programming (i. e. outside the context of teaching)? Would you recommend that?

Also, the requirement to check eof. Maybe it isn’t just clear that the program will stall if you leave them out. Have you tried compiling and using the example program? Without the eof? Maybe you can phrase it better. Maybe it even requires a better example program, which tries to make read/readLn “usable” for a production program (in an interactive mode).

I, on the other hand, don’t understand why you inserted input in the intro. It is sort of redundant. The § “Signature” already says “If no source is specified, input is assumed.” Also, AFAIK input is of the data type text, so the first sentence of the article is doubly redundant now. I would revert that edit now, unless there are reasons.

Trev, I mentioned readStr. I think it should be mentioned, because sysUtils.strToInt will require you to use the sysUtils unit and implicitly to use a compiler mode supporting exceptions. readStr doesn’t impose these constraints and yet is as convenient as the read/readLn procedures. Don’t you think?

Kai Burghardt (talk) 10:28, 26 May 2020 (CEST)

Kai Burghardt Stating that console applications that use read(ln) are only of interest for teaching purposes is wrong MHO. Would you consider something like a replacement for cmd.exe something you "roll out to the average customer"?

I put "input" in the intro, because the mention of it later on in the page is way too far down. At first glance, it looked like Read(Ln) was only supposed to read from a file. If I were a beginner, I would stop reading after that sentence, if I was looking for a procedure that would read from user input.

The example program asks for user input and then quits on correct input or on EOF. Clearly this demo wasn't meant to read from e.g. a pipe (in which case a check for EOF is a good idea), but for interactive user input from the console. Do you really expect the end-user of this program (users know nothing about programming) to enter a EOF character to quit the application if they insist on not entering a valid number? A more suitable solution would be to let the program quit (and tell the user as such) when an empty string is entered.

--Bart (talk) 12:36, 26 May 2020 (CEST)