Re: Parameterised 'Image Attributes

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2023-08-28 19:33, G.B. wrote:
> On 28.08.23 18:09, Dmitry A. Kazakov wrote:
>> On 2023-08-28 17:42, Stephen Davies wrote:
>>> On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
>>>> On 2023-08-28 11:18, Stephen Davies wrote:
>>>> This will not happen either. But here I would agree, it is clearly a
>>>> case of language littering.
>>>
>>> Littering, schmittering, how about adding Bin_Image, Oct_Image & 
>>> Hex_Image
>>> for Ints and Dec_Image for Ints & Reals ;-)
>>
>> Bin_Width_1_Image, Dec_Width_4_Image and so on... Cool, make Ada C 
>> again! (:-))
> 
> Or maybe leave type attributes alone. Instead, let Ada.Streams
> have I/O manipulating setters.
> 
> Then,  in order to preserve the meaning of "corresponding S'Output"
> (LRM 13.13.2) for every S'Input, add AI to the Ada run-time system.

I like the idea of unification of serialization and formatting.

However it does not solve the problem of parameters. In GUI frameworks 
facing this very problem the parameters for rendering are set into the 
graphic context/surface.

E.g. in the case of string formatting you would need a global object to 
set the parameters into. E.g. a set of procedures like 
Ada.Text_IO.Set_Field_Width, Ada.Text_IO.Set_Integer_Base etc. That 
would be incredibly boring and unsafe.

For stream serialization the parameters could be set on the stream 
itself. Which might break a lot of code if you added them to 
Root_Stream_Type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de