Re: Initialization Params for Controlled Types

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

In article <CyBsE5.GFs@dit.upm.es>, Angel Alvarez <aalvarez@maja> wrote:

>Given that Initialization for Controlled types only takes a single
>parameter, the Object to initialize, how can one actually pass 
>at run-time other data to help initialize the object in one way or
>another? ... Passing them as record fields of the object itself?

The normal way to "construct" an object in a parameterized way in Ada
is with a function.  There is no separate notion
of "constructor" -- functions are used to do construction.
Internally, a function would typically use aggregates and/or
allocators to complete the job of construction.

E.g.:
      X : My_Type := Foo(a, b, c);

This means that "constructors" in Ada are just normal functions,
and their name can give you a clue as to what they are doing
(unlike in some other unnamed OO languages ;-).

Initialize is really for *default* initialization only,
where parameterization (beyond discriminants that control
size/shape) is generally unnecessary.

The one place where a function doesn't work for parameterized
initialization is for an object of a limited type (and even that
is not a problem if you generally use access values to refer
to such objects).  In this case, one way to parameterize the
initialization of a limited object is by discriminants.  
In Ada 9X, discriminants are more general, and can be of
an access type.  This allows you to "pass in" essentially anything
to the (default) initialization (using 'Access if necessary).

For a limited object, it is also generally reasonable
to call an explicit initialization procedure with any number
of parameters.  Again, the primary goal of Initialize is to
provide *default* initialization.  Explicit parameterized 
initialization can be performed in other ways (via functions
or procedures).

>It is unclear to me how this could be done for Controlled objects  
>(by means of default field initialization for the record type itself?) 
>and at any rate it seems like this solution might introduce "excess baggage" 
>for the whole life of the object, just to have on hand the data 
>required at initialization time ... Will anybody please like to comment?

See above.  It is true that for limited objects, the data used
for default initialization needs to be accessible via the discriminants.
But again, remember we are talking about default initialization.
Explicit parameterized initialization can be accomplished using 
functions and/or procedures.

>Thank you for your help,
>Angel Alvarez

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

P.S. Even if the size of the object being constructed is large,
there is no need for a "constructor" concept distinct from functions.
Functions are generally just as efficient in decent implementations.

In most implementations, if a function returns a large object, the 
caller passes in the address of a location where to put the result.  
When used in an initialization context, this location can be the 
target object itself (since the object doesn't exist yet, there is no harm
in using it as the "temp" in which to put the return value).

Furthermore, it has become quite common for compilers to implement
a "return" optimization where if all return statements return
the same local variable, then that "local" variable actually resides
in the return "temp" allocated by the caller.  The net effect
is that the function "constructs" the result directly in its final
resting place, and no extra copying (or "adjusting") is performed.
-T