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)

I don’t say read/readLn were merely useful in teaching.

Command lines (for interactive usage) aren’t programmed using read/readLn. How would you implement command expansion (hitting the tab-character)?

But input is a text file. Am I misinformed about that? Maybe the compiler implements it differently, but for the user/programmer it is a text file. Before the “or” it says, you can use these procedures to read from a text file. This includes input.

I clearly have robust programming on my mind (and like to propagate that). I think it’s a bad habit to assume users won’t enter something unexpected or even malicious. The example program is placed under the section production usage, so I think it is fair to treat all possible cases and not just show a – excuse my expression – “teaching demo”.

Kai Burghardt (talk) 11:58, 29 May 2020 (CEST)

talk Yes, input is a text file, but the novice reader does most likely NOT know this. He/she then abandons reading this page after the first sentence. I cannot explain any better than this what I meant.

— Preceding unsigned comment added by Bart (talk • contribs) 2020-05-29T15:45:17

Yeah, I understood that. But I think the novice reader will by then know what input and output are. This page isn’t meant to be a tutorial, but something between encyclopedic article and reference.

And if beginners are really reading this article, the intro is even more misleading: Now the wording suggests that input was something different than a text file (it is mentioned explicitly, there must be a reason for that). [To be fair, this can be resolved by putting it like “… retrieve data from a text file (such as input).”]

I’d still delete it though, leaving the intro as concise as it was before. Kai Burghardt (talk) 17:40, 29 May 2020 (CEST)

Apologize for not signing my previous remark.

Let's agree to disagree on this then. --Bart (talk) 10:55, 30 May 2020 (CEST)

No, worries, mate. This even happens to me sometimes.

I won’t settle for “agree to disagree”. I think my suggestion is a compromise. I don’t like it, but it feels “less wrong” to me than it is now. I’ve changed it accordingly. Kai Burghardt (talk) 14:10, 30 May 2020 (CEST)

Ok. --Bart (talk) 22:09, 30 May 2020 (CEST)