Declaring constants for a abstract tagged type and concrete sub classes

Declaring constants for a abstract tagged type and concrete sub classes

[Serge Robyns]

Hi,

I'm new on Ada OO-programming and I'm facing this dilemma on a class hierarchy.

The idea is to have a root type with some common data parts and common interface and some concrete procedures and functions but to force to have real variables through subclasses.

As such I've therefore the following (using Get/Set as examples only):

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;

As I want this class hierarchy to be usable without access type is was planning to define No_Element constants.  However, the compiler refuses me to create constant variables, as the type is abstract.  This isn't a problem when the record has only a few components, but when there are a lot it is painful, as I was "hoping" to use the No_Element as a part of the No_Element of the subclasses.  This idea came from the Ada Containers.  And to be able to use No_Element in if statements like

Something along:
    
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;


and then:

    A_Concrete : T_Concrete;
    ...
    A_Concrete := A_List.Find (Expression);
       -- A_List could be a complex object with multiple components,
       -- including T_Concrete.
    if A_Concrete = No_Element then
       -- some error handling
    end if;


Any advise on how to handle this need in Ada?  I'll face this issue too in a few potential design patters I want to use (Proxy for example).  Moreover, this constant allows me to initialize variables at the moment of my choice;

Regards,
Serge

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

[G.B.]

On 06.07.15 12:10, Serge Robyns wrote:
> 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;

In case you can afford a publicly abstract but
privately non-abstract type,

package Abstract_Root is
    type T_Root is abstract tagged  private;
    procedure Set_XYZ (Self: in out T_Root; ABC : in Integer);
    function Get_XYZ (Self: in T_Root) return Integer;
    No_Element : constant T_Root;  -- or T_Root'Class;
private
    type T_Root is tagged record
       XYZ : Integer;
    end record;
    No_Element : constant T_Root := T_Root'(Xyz => 666);
end Abstract_Root;

Every object needs to be of a concrete type, whether constant
or not.

If what is wanted is some information about any object
in T_Root'Class (its derivation hierarchy), such as
being a "special" object acting as "no object", say,
a function (to override) might do.

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

[Serge Robyns]

On Monday, 6 July 2015 13:55:02 UTC+2, G.B.  wrote:
> On 06.07.15 12:10, Serge Robyns wrote:
> > 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;
> 
> In case you can afford a publicly abstract but
> privately non-abstract type,
> 
> package Abstract_Root is
>     type T_Root is abstract tagged  private;
>     procedure Set_XYZ (Self: in out T_Root; ABC : in Integer);
>     function Get_XYZ (Self: in T_Root) return Integer;
>     No_Element : constant T_Root;  -- or T_Root'Class;
> private
>     type T_Root is tagged record
>        XYZ : Integer;
>     end record;
>     No_Element : constant T_Root := T_Root'(Xyz => 666);
> end Abstract_Root;
> 
> Every object needs to be of a concrete type, whether constant
> or not.
> 
> If what is wanted is some information about any object
> in T_Root'Class (its derivation hierarchy), such as
> being a "special" object acting as "no object", say,
> a function (to override) might do.

Seems not to work as expected, at least not on GNAT 2015.

If I use No_Element : constant T_Root; => I get "type of object cannot be abstract" compile error, which is what I used to have.  I thought your solution was to address a freezing rule issue.

When I use 'Class I get "type of aggregation cannot by class-wide" compile error.

Currently, I'm using an access pointer and use null to validate the result of searches.  It works fine, but I'm having for example Ada Containers that merely contains a access pointer to the an allocated object.  And the whole pointer mess I would love to avoid.  This is how I used to work in my C-days, while I've chosen Ada for my project for a set of reasons such as readability, reliability and it's track record in mission critical systems.

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

[Simon Wright]

Serge Robyns <serge.robyns@gmail.com> 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.

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

[Serge Robyns]

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

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

[Bob Duff]

Serge Robyns <serge.robyns@gmail.com> writes:

> 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);

One possibility is to declare T_Root with default values for the
components, such that those defaults are what you want for a "No_...".
Then you can do:

    No_Sub_Element : T_Sub := (T_Root with X => X, Y => Y, Z => Z);

Or if T_Sub also has meaningful defaults, then:

    No_Sub_Element : T_Sub := (T_Root with others => <>);

I don't much like using default values, but in this kind of case
it might be the best choice.

- Bob

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

[gautier_niouzes]

Not sure if it is useful for you, but sometimes I define a "pre-root" type which is concrete from which I define a root type which is abstract.

http://excel-writer.sf.net/ew_html/excel_out__ads.htm#462_8

In the example, the "official" root type is actually:

  type Excel_Out_Stream is abstract new Excel_Out_Pre_Root_Type with null record;

_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address 

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

[G.B.]

On 06.07.15 15:49, Serge Robyns wrote:

>> In case you can afford a publicly abstract but
>> privately non-abstract type,
>>
>> package Abstract_Root is
>>      type T_Root is abstract tagged  private;
>>      procedure Set_XYZ (Self: in out T_Root; ABC : in Integer);
>>      function Get_XYZ (Self: in T_Root) return Integer;
>>      No_Element : constant T_Root;  -- or T_Root'Class;
>> private
>>      type T_Root is tagged record
>>         XYZ : Integer;
>>      end record;
>>      No_Element : constant T_Root := T_Root'(Xyz => 666);
>> end Abstract_Root;
>>
>> Every object needs to be of a concrete type, whether constant
>> or not. (...)

> Seems not to work as expected, at least not on GNAT 2015.

Just FTR, this is a working example, tested with GNAT 2015;
did you change T_Root to concrete in the private part of
Abstract_Root, leaving it abstract only in the public part?
Is your constant No_Element perhaps declared outside Abstract_Root?

 > If I use No_Element : constant T_Root; => I get "type of object 
cannot be abstract" compile error

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

[Serge Robyns]

On Monday, 6 July 2015 19:02:13 UTC+2, Bob Duff  wrote:
> Serge Robyns <> writes:
> 
> > 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);
> 
> One possibility is to declare T_Root with default values for the
> components, such that those defaults are what you want for a "No_...".
> Then you can do:
> 
>     No_Sub_Element : T_Sub := (T_Root with X => X, Y => Y, Z => Z);
> 
> Or if T_Sub also has meaningful defaults, then:
> 
>     No_Sub_Element : T_Sub := (T_Root with others => <>);
> 
> I don't much like using default values, but in this kind of case
> it might be the best choice.
> 
> - Bob

I agree with you I don't like using default values as they will always initialize variables, even if they will be assigned some other values later.  For the moment (in my prototype) they are useful as not all data is yet useful populated.

One thing I'm still very much puzzled is the use of "<>" at many places.  I'm fine with it in generics, but failed to understand in class declaration or your assignment examples.  Looks like I failed to understand some chapters.  I did google to understand their use in abstract tagged types (found an example of a Virtual Proxy example in Ada using that kind of construct).


Serge

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

[Serge Robyns]

On Monday, 6 July 2015 19:37:00 UTC+2, G.B.  wrote:
> On 06.07.15 15:49, Serge Robyns wrote:
> 
> >> In case you can afford a publicly abstract but
> >> privately non-abstract type,
> >>
> >> package Abstract_Root is
> >>      type T_Root is abstract tagged  private;
> >>      procedure Set_XYZ (Self: in out T_Root; ABC : in Integer);
> >>      function Get_XYZ (Self: in T_Root) return Integer;
> >>      No_Element : constant T_Root;  -- or T_Root'Class;
> >> private
> >>      type T_Root is tagged record
> >>         XYZ : Integer;
> >>      end record;
> >>      No_Element : constant T_Root := T_Root'(Xyz => 666);
> >> end Abstract_Root;
> >>
> >> Every object needs to be of a concrete type, whether constant
> >> or not. (...)
> 
> > Seems not to work as expected, at least not on GNAT 2015.
> 
> Just FTR, this is a working example, tested with GNAT 2015;
> did you change T_Root to concrete in the private part of
> Abstract_Root, leaving it abstract only in the public part?
> Is your constant No_Element perhaps declared outside Abstract_Root?
> 
>  > If I use No_Element : constant T_Root; => I get "type of object 
> cannot be abstract" compile error

I found the issue ...
In the private part I still had a type T_Root is abstract tagged record.
This is why I did put it aside for a while and then re-look at it afresh.

Now I'm facing my other issue, how to "merge" the root and child part in a new No_Element ...  This is about valid Ada syntax.

No_Element : constant T_Concrete := ( T_Root.No_Element, 789);

This gets expectingly rejected.  And I'm facing my inexperience in Ada.

Serge

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

[G.B.]

On 07.07.15 18:27, Serge Robyns wrote:

> Now I'm facing my other issue, how to "merge" the root and child part in a new No_Element ...  This is about valid Ada syntax.

> No_Element : constant T_Concrete := ( T_Root.No_Element, 789);

If the derived type stays within the package hierarchy,
i.e. in a child package (that's Abstract_Root.No_Element
in the extension aggregate):

...
private
   No_Element : constant Non_Abstract :=
      Non_Abstract'(No_Element with
                    Abc => -42);

That is, one can start an extension aggregate with
an expression supplying the T_Root stuff from the parent
type. Or,

...
private
   No_Element : constant Non_Abstract :=
      Non_Abstract'(T_Root with
                    Abc => -42);

where T_Root stands for the type's defaults only.
Outside the hierarchy, that could be

...
private
   No_Element : constant Non_Abstract :=
     Non_Abstract'(Abstract_Root.T_Root with
                   Abc => -42);

This presumes, then, that no_element-ness is fully determined
by the component Abc here, since Abstract_Root.No_Element's
private view is unavailable outside the package hierarchy
and so can't be depended upon.

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

[Serge Robyns]

On Tuesday, 7 July 2015 19:21:46 UTC+2, G.B.  wrote:
> On 07.07.15 18:27, Serge Robyns wrote:
> 
> > Now I'm facing my other issue, how to "merge" the root and child part in a new No_Element ...  This is about valid Ada syntax.
> 
> > No_Element : constant T_Concrete := ( T_Root.No_Element, 789);
> 
> If the derived type stays within the package hierarchy,
> i.e. in a child package (that's Abstract_Root.No_Element
> in the extension aggregate):
> 
> ...
> private
>    No_Element : constant Non_Abstract :=
>       Non_Abstract'(No_Element with
>                     Abc => -42);
> 

This one did the trick!  I'm marveled by the syntax and the meaning of the standalone tick (').  I'm wondering how I'll master these idiosyncrasies.  I've tried to read years back the 95 RM but honestly it isn't bedtime lecture.  The wiki book is much readable but seems to leave quite some ground unexplored.  And I must admit I don't capture the essence of the difference between the above one and below one, except the obvious (variable vs. type) it puzzles me that it builds a variable out of type definition.

> That is, one can start an extension aggregate with
> an expression supplying the T_Root stuff from the parent
> type. Or,
> 
> ...
> private
>    No_Element : constant Non_Abstract :=
>       Non_Abstract'(T_Root with
>                     Abc => -42);
> 
> where T_Root stands for the type's defaults only.
> Outside the hierarchy, that could be
> 
> ...
> private
>    No_Element : constant Non_Abstract :=
>      Non_Abstract'(Abstract_Root.T_Root with
>                    Abc => -42);
> 
> This presumes, then, that no_element-ness is fully determined
> by the component Abc here, since Abstract_Root.No_Element's
> private view is unavailable outside the package hierarchy
> and so can't be depended upon.

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

[Simon Wright]

Serge Robyns <serge.robyns@gmail.com> writes:

> On Tuesday, 7 July 2015 19:21:46 UTC+2, G.B.  wrote:
>> On 07.07.15 18:27, Serge Robyns wrote:
>> 
>> > Now I'm facing my other issue, how to "merge" the root and child
>> > part in a new No_Element ...  This is about valid Ada syntax.
>> 
>> > No_Element : constant T_Concrete := ( T_Root.No_Element, 789);
>> 
>> If the derived type stays within the package hierarchy,
>> i.e. in a child package (that's Abstract_Root.No_Element
>> in the extension aggregate):
>> 
>> ...
>> private
>>    No_Element : constant Non_Abstract :=
>>       Non_Abstract'(No_Element with
>>                     Abc => -42);
>> 
>
> This one did the trick!  I'm marveled by the syntax and the meaning of
> the standalone tick (').

In this case you really don't need the Non_Abstract'; as evidenced by
my post in this thread yesterday, which I wouldn't have posted had it
not compiled.

   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;

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

[Jeffrey R. Carter]

On 07/07/2015 12:51 PM, Serge Robyns wrote:
> 
> This one did the trick!  I'm marveled by the syntax and the meaning of the
> standalone tick (').  I'm wondering how I'll master these idiosyncrasies.
> I've tried to read years back the 95 RM but honestly it isn't bedtime
> lecture.  The wiki book is much readable but seems to leave quite some ground
> unexplored.  And I must admit I don't capture the essence of the difference
> between the above one and below one, except the obvious (variable vs. type)
> it puzzles me that it builds a variable out of type definition.

Yes, the ARM is not a good way to learn the language, and the wiki book leaves
some things to be desired. If you have experience with another language, I
recommend /Ada Distilled/:

http://www.adaic.org/wp-content/uploads/2010/05/Ada-Distilled-24-January-2011-Ada-2005-Version.pdf

If you'd like more of a beginner's introduction, there's /Ada 95: The Craft of
Object Oriented Programming/:

http://archive.adaic.com/docs/craft/craft.html

Both are freely available on line.

-- 
Jeff Carter
"I've seen projects fail miserably for blindly
applying the Agile catechism: we're Agile, we
don't need to stop and think, we just go ahead
and code!"
Bertrand Meyer
150