Re: Constructors for Ada (was: Converting C++ class to Ada)

[mheaney@ni.net (Matthew Heaney)]

In article <32B17EFC.4BC7@watson.ibm.com>, ncohen@watson.ibm.com wrote:

>> The issue I have with the language is that there is an asymmetry between
>> how stack objects are initialized and how heap objects are initialized.
>> 
>> For example, to initialize an object on the heap:
>> 
>> type Integer_Access is access Integer;
>> O : Integer_Access := new Integer'(4);
>> 
>> Why shouldn't I be able to do that for stack objects too?
>> 
>> O : Integer'(4);

[snip]

>
>I don't understand Matthew's point.  Why is the syntax 
>
>   O : Integer'(4);
>
>in any way preferable to 
>
>   O : Integer := 4;
>
>?  After all, if LT is a limited type, it cannot be initialized in
>either an object declaration or an allocator.  That is,
>
>  new LT'(X);
>
>is every bit as illegal as
>
>  O : LT := X;
>
>and for very good reason:  It entails making a copy of X.

I was using that style of initialization as an analogy only.  Sorry about that!

The way the language is now, it's sort of like there's a predefined
constructor that takes the type as an  argument.  For example,

type T is private;

constructor T (Initial_Value : in T);   -- a "built-in" constructor

And for objects on the heap only, I can "invoke" this constructor:

X : T;
O := new T'(X);

What I'm asking for is a way to define other constructors, that take other
than type T as an argument.  For example,

constructor T (File_Name : in String);

Having that would allow me to do this

O : T'(File_Name => "my_file.dat");

Yes, I can already do something very close to that for non-limited types -
by using a function that returns a value of the type.  But my motivation
was being able to that for limited types too.

I can't use a function to return a value of the limited type during
elaboration of a limited object, so I had to invent some other way to do
that.  Thus the new syntax.

I can't do this

function Initial_Value (<custom params here>) return T;
O : LT := Initial_Value (...);

because I don't have assignment for limited types.  So let's solve the
problem by doing this

O : LT'Initial_Value (...);


>Matthew suggests that it would be useful to specify parameters in the
>declaration of a limited object to control how the object is
>initialized.

Yes.

>Since it is already possible to force a limited object to
>have a default initial state, and to change the object's state by
>calling a procedure declared in the same package as the limited type, I
see no compelling need for this.

Then we have a philosophical difference.  I would like to allow the user to
have more control of the initial state of a limited object, by invoking the
constructor of his choice.  And to be able to do it in the declarative
region.

Maybe the need for such a mechanism isn't "compelling," but to me it's in
the "really desirable" category.
 
>(Furthermore, as stated in a previous
>message, the same effect can often be achieved by deriving the limited
>type from Limited_Controlled and giving the type discriminants that are
>read by the type's Initialize procedure.

Again, we have a philosophical difference.  To me using discriminants to
"initialize" an object is a misuse of the language.  I don't believe
discriminants should be used for that purpose.

It seems to me you're fighting the language.  Why fight?  If you really
want to custom initialize an object, why not build in a proper mechanism to
do so?

>> But suppose my type were limited.  For  example, I'd like to open a file
>> during elaboration of the file object:
>> 
>> F : File_Type'(Name => "my_file.dat", Mode => In_File);
>> 
>> That's something I can't do now, because type File_Type is limited private.
>> So I have to do this
>> 
>>    F : File_Type;
>> begin
>>    Open (F, Name => "my_file.dat", Mode => In_File);
>
>What's so bad about with that?

I didn't say it was bad!  It's just that I wanted a uniform way of
initializing objects, that applies irrespective of whether the type is
limited or non-limited.

The syntax rules prevent one from initializing a limited object in the
declarative region (because no assignment is available).  Why should
initialization of limited objects have to be done differently?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271