From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Text_IO, was: Re: Something I don't understand Date: Mon, 17 Feb 2014 12:52:21 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <4a3e55f6-9f54-4084-9f37-96efd4b0d349@googlegroups.com> <0b358700-871b-4603-addd-65e07c7d59e5@googlegroups.com> Injection-Date: Mon, 17 Feb 2014 12:52:21 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="2381"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Tfjf8Sge+Uw2HeQ0AFIFbyeDgMoazYEc=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:jL3BtADNIj5gxVIZLfdBn5ri6uI= Xref: number.nntp.dca.giganews.com comp.lang.ada:184931 Date: 2014-02-17T12:52:21+00:00 List-Id: On 2014-02-16, Robert A Duff wrote: > Simon Clubley writes: > >> On 2014-02-15, Robert A Duff wrote: >>> >>> FWIW, Text_IO is a poor design, and I don't blame you for having >>> trouble with it! >> >> I'm always interested in learning how people would do things differently >> if they were given a second chance. >> >> So, what do you dislike about Text_IO and what design changes would you >> make if given a second chance ? > > I/O should be separated from processing. In this case, the "processing" > I'm talking about is formatting and parsing of data (e.g. turning > an integer into a human-readable sequence of characters). See how > it's done in Java. > > Formatting for type T belongs with type T, not in Text_IO. > Agreed, but it should be a two-way thing. There should be both External_To_Internal and Internal_To_External support to convert between the external (human readable) format and the internal format. You would also need to specify a format when going from internal to external format so the output would fit in the requested field width and obey the requested attributes (for example, number of decimal places). > Input should be separate from output. Put(Stream, X), where X is an > integer makes sense, because we know X is an integer. Get(X) > makes no sense, because we have no idea what the user is going > to type. For text input, you need "read the next token, and tell > me what it is", not "read an integer token, and blow up if the > user typed something else". > While the current input routines need replacing, I don't agree with the Ada RTL trying to work out what the input format is and pass a token type back to the program. The problem is that unless you are careful, you can end up with a Excel type solution in which it works most of the time but fails when it thinks it knows better than you do what you entered. For example, consider the input "123,456". Is the user entering a array of two numbers ? Is the user entering one number but with a thousands seperator ? Is the user in mainland Europe and hence is really entering "123.456" ? Should this input be treated as a string (because it has a comma in it) or should the Ada RTL impose it's idea of a number and convert the input into some standard format even though that may not look anything like what the user meant ? What happens when the final destination is a range limited data type ? You either have to still do the checking manually or take a exception if the input value is outside of the range of the data type. > A simplified and type-safe version of C's printf style > (template-based) formatting would be more readable than > concatenating a bunch of strings together to print messages, > and MUCH better than using a series of Put calls to print > a single message. > _Totally_ agree with this. It would also be nice if one could write something like this (pseudo Fortran style to get the idea across): "5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth (in this example) of data cleanly. > > There should be a convenient way to read an entire file into > a String. Similar for writing. > Yes, but you may need two methods. One for binary (unchanged) input and one for text input with end of line conversions. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world