Re: Constructor in ADA9X

[stt@henning.camb.inmet.com (Tucker Taft)]

DELROEUX JEAN-YVES (jydelr@vub.ac.be) wrote:
:  I would like to know how make a constructor ( like in C++ ) in ADA9X. Is it
: possible ?? If yes how and if not, why and how can I simulate constructors ?

The only "predefined" constructor in Ada 95 is the aggregate
(array, record, and extension aggregates are provided).
All other constructors are simply user-written functions.
Any function that returns T or access-to-T (or T'Class or 
access-to-T'Class) can be considered a constructor.

Since aggregates are only usable when a type's full definition
is visible, only the user-defined "constructors" are
available to clients of a private type.  These user-defined
constructors are presumably implemented internally using
an aggregate (or simply a series of assignments).

Note that some constructors in C++ are used to perform
default initialization.  This is provided in Ada 95
through normal record component defaults (as in Ada 83)
plus an optional user-defined Initialize procedure
for "controlled" types (those descended from 
Finalization.[Limited_]Controlled).  Because 
record component defaults are generally sufficient for
default initialization, an explicit Initialize procedure is 
not often needed.

Other constructors in C++ are used as "copy" constructors.
This facility is provided in Ada 95 via the Adjust procedure
for controlled types.

While I am at it -- destructors are provided via the Finalize
procedure for controlled types.

One last point -- sometimes you don't want a constructor
to be inherited, because the set of parameters it takes
is dependent on the specific type for which it was designed.
If you declare the constructor in the same package as the
associate type T, and it returns the type T, then it *will*
be inherited.  One nice way to avoid undesired inheritance for
certain constructors is to put all such constructors in 
a "child" package of the package where the original type
is defined.  

For example, if you have a type T declared in a package 
P, then such constructors could be declared in a child 
such as "P.Constructors" or "P.Factory".  Since, typically, fewer 
clients use constructors than use other operations on a type, this 
separation corresponds to a natural dividing line in the clients of an
abstraction.  Furthermore, it means you can add or modify the
set of constructors without disturbing code that only manipulates
already-constructed objects.  You can also partition the
constructors into multiple groups by creating multiple child
"constructor" packages, if that makes sense for a given
abstraction.

: 	Thanks for your help.

: 	DELROEUX Jean - Yves

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