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 10.107.31.137 with SMTP id f131mr10263747iof.7.1518471698173; Mon, 12 Feb 2018 13:41:38 -0800 (PST) X-Received: by 10.157.94.15 with SMTP id d15mr492847oti.4.1518471698008; Mon, 12 Feb 2018 13:41:38 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!w142no1122109ita.0!news-out.google.com!m16ni2621itm.0!nntp.google.com!o66no1116939ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 12 Feb 2018 13:41:37 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a01:e35:2ecd:88c0:a4f5:2be0:1b19:1ea0; posting-account=O1Kt4QoAAABKYAjrg-cGai_vZLnN2LEw NNTP-Posting-Host: 2a01:e35:2ecd:88c0:a4f5:2be0:1b19:1ea0 References: <575826a1-c983-49aa-95e2-54048f6b7b5b@googlegroups.com> <3b72aae1-7ff4-48a9-a154-f17cd6784334@googlegroups.com> <7f5fec97-6ae6-4833-87df-77aac5a8e4ff@googlegroups.com> <191ef0a8-865e-49be-baa6-6c5c2d0b55fc@googlegroups.com> <39661f79-1df7-41fb-8bf9-fec1d60da217@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <68b0607f-faa4-476e-b830-d28028759a75@googlegroups.com> Subject: Re: [ANN] List_Image v0.2.0 From: Lionel Draghi Injection-Date: Mon, 12 Feb 2018 21:41:38 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 1446393204 X-Received-Bytes: 6329 Xref: reader02.eternal-september.org comp.lang.ada:50400 Date: 2018-02-12T13:41:37-08:00 List-Id: Le lundi 12 f=C3=A9vrier 2018 11:57:18 UTC+1, Stefan...@uni-weimar.de a =C3= =A9crit=C2=A0: > Thank you, the List_Image package is really cool! Thank you Stefan, what is cool is to read such a feedback! ... > To avoid code duplication, would it not be better to define a single=20 > generic package Predefined_Styples with a parameter EOL, and then creat= =20 > the same two packages by instantiation in the spec of List_Image, as=20 > below? >=20 > package Windows_Predefined_Styles is new > Predefined_Styles(EOL =3D> Windows_EOL) >=20 > package Unix_Predefined_Styles is new > Predefined_Styles(EOL =3D> Unix_EOL) Yes, that's perfectly right. That's why I said "I felt another generic woul= d be too much. YMMV".=20 So, your mileage vary :-) OK, I was a bit too lazy, I guess :-)=20 > Point 2: >=20 > The entire approach gets in trouble if you ever generate and store a=20 > string on windows, but then use Unix to process ist, or vice versa.=20 By using the right generic you can generate the both version, whatever is y= our platform. That's why I sometimes use "target platform" in the doc, and not "current p= latform". As you said, there is a potential problem if generating a string, and using= it on a different platform. But this is a seldom problem, often taken into= account outside of the program (for example you can change the line termin= ator with git according to the system where you clone the code).=20 Some lib provide automatic conversion functions (cf. the Python discussion = in the same thread), but that's out of scope for me here. After all, you can't do it with Text_IO: there is no Put_Line (Item, File, = Format =3D> Windows); I don't try to be more catholic than the pope :-) =20 > portability, it might be better to fix an arbitrary line terminator -- LF= ,=20 > or CRLF or whatever, as long as it does never ocur as a part of a line=20 > itself -- and then delegate the problem of properly printing a sequence o= f=20 > lines to the user. >=20 > Oh, instead of delegating the problem to the user, you could even solve i= t=20 > for the user by defining a child package >=20 > package List_Image.Text_IO is >=20 > procedure Put_Lines(Lines: String; EOL: String); >=20 > end List_Image.Text_IO; >=20 > The implementation would "with Ada.Text_IO", and then iterate through the= =20 > individual lines in Lines, calling Ada.Text_IO.Put_Line for each line. If= =20 > EOL=3D"", Put_Lines will assume a single-line represenation and just call= =20 > Ada.Text_IO.Put_Line(Lines); >=20 > Unlike your current approach, this would allow implementations to be=20 > completely independent from the operation system's line termination=20 > convention. >=20 > Of course, the user should always use List_Images.Text_IO.Put_Lines, to= =20 > print the output from List_Images.Image. Calling Ada.Text_IO directly=20 > would be a compatibility issue. Consequently, you could (re-)define >=20 > type Image_String is new String; >=20 > generic > with package Cursors is new Cursors_Signature (<>); > with function Image (C : Cursors.Cursor) return String is <>; > with package Style is new Image_Style (<>); > function Image (Cont : in Cursors.Container) return Image_String; >=20 > and >=20 > procedure Put_Lines(Lines: Image_String; EOL: String); >=20 > Would that make sense to you? Yes. Those points where discussed before in the thread.=20 It make sense, but instead of just defining a specific Put_Lines procedure,= I do a little step further (even if it add some more complexity) : I intend to define a "Text" abstraction that is a vector of String : and fo= r multi-line styles, I'll use this Text type instead of String. This way, I don't have to define a specific line terminator, and there is n= o limitation on what can be in the String. I'll provide a Put_Text procedure that will call Text_IO.Put_Line on each T= ext line, and will no more have to care of the EOL definition. And, BTW, it will also solve the first problem of code duplication. On the other hand, what will be lost (at first glance) is the ability to pr= ovide an output for another platform. But, as I said, I consider this featu= re not really in the scope, conversion between text format should be done e= lsewhere.=20 Not sure it will end well, but let's see! Lionel