Re: Declaring constants for a abstract tagged type and concrete sub classes

[Serge Robyns <serge.robyns@gmail.com>]

On Monday, 6 July 2015 17:42:10 UTC+2, Simon Wright  wrote:
> Serge Robyns <> writes:
> 
> > package Abstract_Root is
> >    type T_Root is abstract tagged with private;
> >    procedure Set_XYZ (Self: in out T_Root; ABC : in Integer);
> >    function Get_XYZ (Self: in T_Root) return Integer;
> > private
> >    type T_Root is abstract tagged record
> >       XYZ : Integer;
> >    end record;
> > end Abstract_Root;
> 
> > package Concrete is
> >    type T_Concrete is new T_Root with private;
> >    No_Element : constant T_Concrete;
> >    ....
> > private
> >    type T_Concrete is new T_Root with record
> >       ...
> >    end record;
> >    No_Element : constant T_Concrete := (Abstract_Root.No_Element, ...);
> > end Concrete;
> 
> You could write
> 
>    with Abstract_Root;
>    package Concrete is
>       type T_Concrete is new Abstract_Root.T_Root with private;
>       No_Element : constant T_Concrete;
>    private
>       type T_Concrete is new Abstract_Root.T_Root with record
>          ABC : Integer;
>       end record;
>       No_Element : constant T_Concrete
>         := (Abstract_Root.T_Root with ABC => -42);
>    end Concrete;
> 
> (or whatever will suit you)
> 
> but I think you'll have to give T_Root.XYZ an equivalent default value,
> or equality won't work.

Dear Simon,

Thank you, you seem to confirm my understanding of the "correct" way of doing this.

I'm actually even wondering how to implement such an assignment for non abstract classes with records.  For example:

type T_Root ...
No_Root_Element : T_Root := (a, b, c);

type T_Sub is new T_Root ....
No_Sub_Element : T_Sub := ( ??? No_Root_Element ???, x, y z);

I'm very much doubting a valid Ada Syntax and hence my whole idea is of no use.
The issue is that the root class could end-up with a lot of data and the sub classes with much less, they are actually special cases of the generic root class.

If this doesn't work well, I'll use the decorator pattern to address this issue, as this seems to be the most applicable one and can be recursive, which I'll need anyway, because at the very end, I'll use decorators to create more specialized instances of the previous one.

Regards,
Serge