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

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <mheaney-ya023280001312961835130001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

 > 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.

   Let's see.  In Ada 83 the concept of limited types was introduced
to allow treatment of task objects to be consistant with that of other
objects.  As a result you can have objects with tasks as components,
etc.  But the characteristic of limited types is that they don't have
an assignment operation.  (By default limited types don't have "="
either, but an "=" function can be added, as can a ">", etc.)

   Having said that, Ada 95 went through several gyrations about
functions returning limited types.  The final result is at
6.5(11..21) and defines "return-by-reference" types.  The net effect
of all this is that you can have a function returning a limited type,
take 'ACCESS of the call and assign it to an access value:

   type File_Access is access Text_IO.File_Type;

   function Open(Name: in String;
                 Mode: in Text_IO.File_Mode := Text_IO.In_File;
                 Form: in String := "")
          return Text_IO.File_Type;
   ...

   A_File: File_Access := Open("My_File")'Access;
   ...

   Text_IO.Close(A_File.all);

   If you think it is cleaner you can even define Open to return a
value of type File_Access, but I don't recommend it.  RM 3.10.2(10)
has another bit of magic about functions which have
return-by-reference return values.  The static nesting depth of the
return value is that of the scope containing the body of the function.
This allows you to avoid accessability checks and not be required to
manage the garbage collection.  (In most implementations, the used
file objects will be reclaimed when you exit the scope where the open
function was declared, so there are cases where you do want to nest
it.)

   (Of course you can be clever and define two functions, one of which
calls the other, and either hope that the comiler figures out that the
accessability check can be made statically, or use inlining to provide
a clue.)

 > 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?

   Because no assignment is availiable?  Remember that there are going
to be limited objects for which assignment is not available anywhere,
such as objects containing tasks or protected objects.  But notice
that you are not prevented from initializing limited objects in a
declarative region, you are only prevented from doing it by
assignment.  That is a prohibition that is not specific to declarative
parts.  Of course it is REAL ugly to initialize an object as the side
effect of a later declaration, but it is not prohibited.


--

					Robert I. Eachus

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