Deriving from non-null abstract type

Deriving from non-null abstract type

[Moti Ben-Ari]

I would like to derive from a _non-null_ abstract tagged type:

  type Abstract_Type is abstract tagged
    record
      General_Info: Some_Type;
    end record;

  type Derived_Type is new Abstract_Type with
    record
      Special_Info: Some_Other_Type;
    end record;

Of course, you can't create a value of the abstract type,
but it turns out that it is impossible to create a value
of the derived type:

    D: Derived_Type := (G with S);

because G would have to be an aggregate of an abstract type 
which is illegal. The only thing you can do is:

  D: Derived_Type := (Abstract_Type with S);

which means that the component General_Info has to
be initialized in a separate statement.
This seems to be against the philosophy of Ada which
provides aggregates so that you won't forget to initialize
a component.

Is there some way of creating a value that I don't see?
If not, why aren't abstract types restricted to null records?

Moti

Moti Ben-Ari
benari@datasrv.co.il

Re: Deriving from non-null abstract type

[Tucker Taft]

Moti Ben-Ari (benari@zeus.datasrv.co.il) wrote:
: I would like to derive from a _non-null_ abstract tagged type:

:   type Abstract_Type is abstract tagged
:     record
:       General_Info: Some_Type;
:     end record;

:   type Derived_Type is new Abstract_Type with
:     record
:       Special_Info: Some_Other_Type;
:     end record;

: Of course, you can't create a value of the abstract type,
: but it turns out that it is impossible to create a value
: of the derived type:

:     D: Derived_Type := (G with S);

: because G would have to be an aggregate of an abstract type 
: which is illegal. 

There is no need to use an extension aggregate at all.  You
can use "regular" record aggregates if you are giving all of the
components of a record extension, including those inherited from the 
parent type.  Hence, the following is the appropriate way to initialize
all of the components of a record extension:

    D : Derived_Type := 
           (General_Info => General_Value, Special_Info => S);

or positionally:

    D : Derived_Type (General_Value, S);

: ... The only thing you can do is:

:   D: Derived_Type := (Abstract_Type with S);

: which means that the component General_Info has to
: be initialized in a separate statement.

This kind of aggregate is to be used when you want to 
default-initialize the inherited components.  If you want
to initialize them, then as indicated above, just use
a regular record aggregate.

: This seems to be against the philosophy of Ada which
: provides aggregates so that you won't forget to initialize
: a component.
: Is there some way of creating a value that I don't see?

Yes -- use a regular record aggregate.

: If not, why aren't abstract types restricted to null records?

See above.

: Moti

: Moti Ben-Ari
: benari@datasrv.co.il

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.

Re: Deriving from non-null abstract type

[Robert I. Eachus]

In article <3lbh2q$8ov@israel-info.datasrv.co.il> benari@zeus.datasrv.co.il (Moti Ben-Ari) writes:

  > Of course, you can't create a value of the abstract type,
  > but it turns out that it is impossible to create a value
  > of the derived type...

   Not quite true, but it is a very good question.  It is illegal to
create an object or an aggregate of an abstract type:

  >     D: Derived_Type := (G with S);

  > because G would have to be an aggregate of an abstract type 
  > which is illegal. The only thing you can do is:

     ...but G is not required to be an aggregate, it is required to be
a subtype name or an expression.  Also, there is no requirement to use
an extension aggregate.  If you want to initialize the entire
record--and have the visibility to do it--you can use a simple
aggregate:

       D: Derived_Type := (G,S);

  Also Moti Ben-Ari discussed the subtype case:

 >     D: Derived_Type := (Abstract_Type with S);

 > which means that the component General_Info has to
 > be initialized in a separate statement.

   ...but missed the fact that the part of the object corresponding to
the parent type does get initialized if the parent type has default
expressions.  Also, the record component association list can override
any default assignments to components of the parent type, so it is
possible, just not required, to initialize all components.

   An interesting philosophical question is whether the prohibition on
aggregates of an abstract type in 3.9.3(7) was intended to apply to
this case.  I suspect not, but I don't think the ARG should consider
"fixing" it.  There doesn't seem to be any lost functionality--and
conversely it doesn't seem difficult to allow--but I don't see any
advantage to a change which is purely a syntactic patch to make
extension aggregates easier to read in some unusual cases.

     For those who care, going back to Moti's example, the legal way to
initialize the entire record using an extension aggregate is to say:

     D: Derived_Type := (Abstract_Type with General_Info => G,
                          Special_Info => S);
   
     instead of:

     D: Derived_Type := ((General_Info => G) with Special_Info => S);

  > Is there some way of creating a value that I don't see?

    Yep, see above.  Two of them.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Deriving from non-null abstract type

[Tucker Taft]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: ...
:    An interesting philosophical question is whether the prohibition on
: aggregates of an abstract type in 3.9.3(7) was intended to apply to
: this case.  I suspect not,  ...

Yes it was.  We specifically investigated this issue, and added
the second kind of extension aggregates to handle the case of
extending an abstract private type.  When extending an abstract
nonprivate type, a normal record aggregate is the correct (and only
legal) approach.

: ...
:      For those who care, going back to Moti's example, the legal way to
: initialize the entire record using an extension aggregate is to say:

:      D: Derived_Type := (Abstract_Type with General_Info => G,
:                           Special_Info => S);

Not quite.  Leave out the "Abstract_Type with" part:

       D : Derived_Type := (General_Info => G, Special_Info => S);

: 					Robert I. Eachus

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: Deriving from non-null abstract type

[Dan Johnston D.B.]

In <3lbh2q$8ov@israel-info.datasrv.co.il> benari@zeus.datasrv.co.il (Moti Ben-Ari) writes:

>I would like to derive from a _non-null_ abstract tagged type:

>  type Abstract_Type is abstract tagged
>    record
>      General_Info: Some_Type;
>    end record;

>  type Derived_Type is new Abstract_Type with
>    record
>      Special_Info: Some_Other_Type;
>    end record;

>Of course, you can't create a value of the abstract type,
>but it turns out that it is impossible to create a value
>of the derived type:

>    D: Derived_Type := (G with S);

>because G would have to be an aggregate of an abstract type 
>which is illegal. The only thing you can do is:

You can use an ordinary aggregate
     ( General_Info => Some_Type, Special_Info => Some_Other_Type )

I sympathise because this problem had me hung up for a considerable time too.
You (and I also) obviously expected that an aggregate of an extension type
must be an extension-aggregate, but this is not the case.
The only real confirmation of this that I can find in the manual is the last
example in section 3.9.1 where the Painted_Point aggregate is an example
of an extended type represented as an ordinary aggregate.

Perhaps there should be a note in section 3.9.2 of the manual saying that
aggregates of extended types don't have to be extension-aggregates.
    dan.          dan@cs.uq.oz.au