Re: [ANN] List_Image v0.2.0

[Lionel Draghi <lionel.draghi@gmail.com>]

Le lundi 12 février 2018 11:57:18 UTC+1, Stefan...@uni-weimar.de a écrit :
> 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 
> generic package Predefined_Styples with a parameter EOL, and then creat 
> the same two packages by instantiation in the spec of List_Image, as 
> below?
> 
> package Windows_Predefined_Styles is new
>               Predefined_Styles(EOL => Windows_EOL)
> 
> package Unix_Predefined_Styles is new
>               Predefined_Styles(EOL => Unix_EOL)

Yes, that's perfectly right. That's why I said "I felt another generic would be too much. YMMV". 
So, your mileage vary :-)
OK, I was a bit too lazy, I guess :-) 

> Point 2:
> 
> The entire approach gets in trouble if you ever generate and store a 
> string on windows, but then use Unix to process ist, or vice versa. 

By using the right generic you can generate the both version, whatever is your platform.
That's why I sometimes use "target platform" in the doc, and not "current platform".
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 terminator with git according to the system where you clone the code). 
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 => Windows);
I don't try to be more catholic than the pope :-)  

> portability, it might be better to fix an arbitrary line terminator -- LF, 
> or CRLF or whatever, as long as it does never ocur as a part of a line 
> itself -- and then delegate the problem of properly printing a sequence of 
> lines to the user.
> 
> Oh, instead of delegating the problem to the user, you could even solve it 
> for the user by defining a child package
> 
> package List_Image.Text_IO is
> 
>    procedure Put_Lines(Lines: String; EOL: String);
> 
> end List_Image.Text_IO;
> 
> The implementation would "with Ada.Text_IO", and then iterate through the 
> individual lines in Lines, calling Ada.Text_IO.Put_Line for each line. If 
> EOL="", Put_Lines will assume a single-line represenation and just call 
> Ada.Text_IO.Put_Line(Lines);
> 
> Unlike your current approach, this would allow implementations to be 
> completely independent from the operation system's line termination 
> convention.
> 
> Of course, the user should always use List_Images.Text_IO.Put_Lines, to 
> print the output from List_Images.Image. Calling Ada.Text_IO directly 
> would be a compatibility issue. Consequently, you could (re-)define
> 
>    type Image_String is new String;
> 
>    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;
> 
> and
> 
>    procedure Put_Lines(Lines: Image_String; EOL: String);
> 
> Would that make sense to you?

Yes. Those points where discussed before in the thread. 
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 for 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 no limitation on what can be in the String.
I'll provide a Put_Text procedure that will call Text_IO.Put_Line on each Text 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 provide an output for another platform. But, as I said, I consider this feature not really in the scope, conversion between text format should be done elsewhere. 

Not sure it will end well, but let's see!

Lionel