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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a37:4fc8:: with SMTP id d191mr5150336qkb.177.1587991805361; Mon, 27 Apr 2020 05:50:05 -0700 (PDT) X-Received: by 2002:a4a:df01:: with SMTP id i1mr18842658oou.5.1587991804673; Mon, 27 Apr 2020 05:50:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 27 Apr 2020 05:50:04 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: <26e971a9-6fcc-4e4c-84ee-d74aecd5b217@googlegroups.com> <2c769c87-72f2-4107-b0bf-3846e3ae6c7a@googlegroups.com> <670160da-e66d-446f-a415-27df39d9a73f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <46d53a24-906e-4afc-a5b5-6d3235dfc658@googlegroups.com> Subject: Re: Image attribute (yet again) From: Jere Injection-Date: Mon, 27 Apr 2020 12:50:05 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:58507 Date: 2020-04-27T05:50:04-07:00 List-Id: On Monday, April 27, 2020 at 8:33:31 AM UTC-4, J-P. Rosen wrote: > Le 26/04/2020 =C3=A0 19:33, Jere a =C3=A9crit=C2=A0: > > I'm not saying it can't be done. I'm saying by the time I go through > > all the processing needed, I might as well wrote my own function. It > > makes the existing operation mostly useless (unless I just want a=20 > > temporary debug print that I don't care how it looks). For example, > > if I want to print to a 16x2 character LCD screen and I want to print > > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then > > I need to call Put with an 8 character string, search for the first > > occurrence of '#' (it can be in multiple locations), then overwrite > > a variable number of those characters with 0's (based on the location > > of '#'), and then extract the 4 digits I actually need. All doable=20 > > (not saying it cannot be done), but at that point, I am better off=20 > > just doing my own custom operation instead instead of even using the > > Put operation. =20 > Right. If you want you own format, write it. It will take you less time > than writing this message. For the benefit of everybody, here it is: >=20 > Yep, I do something similar to what you posted. I was just asking if the standard provided something more than what Put provided as it wasn't quite adequate for the general case. =20 It sounds like from your answer that I didn't miss it (I was hoping!). As I said earlier, for stuff like this=20 I have generally rolled my own in Ada. =20 >=20 > > It feels like the Put operation wasn't designed=20 > > with usability in mind. Just the presence of the "16#" and "#"=20 > > around the value makes using the operation more clunky than it=20 > > should be. If that had been left out or if the operation at least > > allowed for padding the actual numeric value inside the result, > > then it would have been much more usable. >=20 > Text_IO was designed for file operations, not so much for interactive > IO. And there is an important feature of Text_IO which is rarely > mentioned: If you use only the appropriate operations from Text_IO (no > 'Image), and your program writes into a file, you can take the sequence > of code that writes the file, replace every Put_* operation by the > symetric Get_* operation, and you will read the file without error. >=20 > This feature requires that if you write a number in a certain base, then > you need to recognize the base when reading. So it's not an error, but a > design decision. Of course, like any design decision, you may agree with > it or not. Conceptionally that makes sense. I do wish they had followed other languages in at least providing some of the basic formatting options for stuff like this. Even if it was a different package (String_IO?).