Re: What's it's name again?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> What do you call private types whose declaration is found in the 
> specification but whose definition is found in the body?  I remember 
> reading/hearing that they have a name (or term) associated with them, 
> but can't remember what it is.

That's not quite legal.  I think you mean a private type completed by an
access type, where the access type points to an incomplete type
completed in the body.  Like this:

    package P is
        type T is private;
    private
        type R; -- completed in body
        type T is access R;
    end P;
    
    package body P is
        type R is
            record
                ...

I call R an "stt incomplete type", and I call T an "stt access type",
named after Tucker Taft (initials "stt"), who invented them around 1982
or so, just before Ada 83 was standardized.  Jean Ichbiah called them
"Taft Amendment Types".

> Are there any complications with moving type definitions to the body? 
> (e.g. with controlled types?).

None other than the fact that you have to have a pointer type involved.
If I need a pointer type anyway, then I use stt access types, but I
don't normally introduce *extra* pointers just to be able to use this
feature.

Introducing extra pointers causes the obvious problems: how do you
allocate and deallocate the pointed-to things?

> I currently have some packages which look like
> 
>    package some_kind_of_data_structure is
> 
>      type data_structure is private;
> 
>    private
> 
>      type data_structure is Ada.Finalized.Controlled with record
>        ...
>      end record;
> 
>    end some_data_structure;
> 
> but have been wondering what would happen if the definitions were
> moved

If you did the obvious thing of moving "type data_structure is
Ada.Finalized.Controlled with record..." to the body, then you would get
an error at compile time.  To make it work, you have to introduce an
incomplete type, and a pointer to it.

> (the obvious benefit is that the package specification does not need to 
> be recompiled when the representation is changed, but is that really a 
> benefit when small numbers of files are involved?)

Yes, that's the obvious benefit, and yes, the benefit depends on how
much code might need to be recompiled.  It could be a lot -- the
transitive closure of the with's of that package spec.

----------------

The main reason normal types need to be completed in the private part
(and not the body) is that the compiler wants to know their size.  For
example, ":=" on a private type needs to know how big it is.  If it were
declared in the body, the size would be a run-time quantity, resulting
in an efficiency hit.  (Consider also, records containing that private
type.  And consider pragma Pack on such records.)

In fact, this sort of thing is the reason for the existence of private
parts.

It's OK for an incomplete type (declared in a *private part*) to be
completed in the body, because, in theory, nobody outside the package
cares about its size.  And pointers to it are always the size of one
address.  (At least that's the theory -- in practise, some compilers
like to have different-sized pointers depending on the designated type,
and stt access types are a headache for them.  Another unexpected
headache is caused by stt-incomplete types that have discriminants.)

Another reason to insist on "normal" types being completed in the
private part might be that the parameter passing mechanism (by copy
vs. by reference) depends on whether the full type is "elementary".  One
would not want that to be a run-time decision.

The whole model here depends on the idea that the compiler can look at
the specs of all with'ed packages (including private parts), but not
their bodies.  Pragma Inline breaks that model, which IMHO makes the
whole model suspect.

- Bob