Re: 'Image for composite types

[Adam Beneschan <adam@irvine.com>]

On May 27, 3:20 pm, Martin <martin.do...@btopenworld.com> wrote:
> Is it just me that gets fed up with the lack of 'Image on composite
> types?
>
> I'm thinking in particular of when I'm testing / debugging and usually
> end up writing lots of 'Put_Line' code for each and every record. And
> then having to maintain them.
>
> It got me thinking that the language could be expanded to include some
> helper attributes for easily composing a function that could return a
> String a la 'Image for scalar types.
>
>    function record_type_definition'Component_Name (I : Positive)
> return String;
>    function record_type_definition'Component_Image (I : Positive)
> return String;
>    function record_type_definition'Number_Of_Components return
> Natural;

This wouldn't work on variant records.  Plus, what does
'Component_Image return if the component type is itself another
record, or an array, or a task?  Or an access?

Plus, in your example below, one of your components is an
Unbounded_String, which is a private type most likely implemented as a
record or access type.  What language rule would make 'Component_Image
of that type return the string value, while 'Component_Image of other
records or access types would do something more pedestrian?

A lot more thought would have to go into this to make it a real
language feature.  Others may have opinions on whether the amount of
effort required to design this feature well, combined with the amount
of effort required for compiler vendors to implement it, is justified
by the benefits.

                                    -- Adam


>    Example
>    =======
>       type Person is
>          record
>             Name   : Unbounded_String;
>             Age    : Natural;
>             Height : Float;
>             Weight : Float;
>          end record;