Re: Proposal: Constructors, Assignment [LONG]

["Nick Roberts" <nickroberts@blueyonder.co.uk>]

Forgive me for not quoting Dmitry's post.

I take the view that the 'object constructor problem' that Ada is sometimes
accused of suffering from is nearly always solved (in a better way than
languages which have special constructor functions) by the old chestnut of:
declaring the type as private (and indefinite) in its own package
specification; providing whichever constructor functions as primitive
operations of this type are appropriate.

The implementation of the type must use an unsophisticated discriminant
scheme, but this is hidden, and the constructor functions translate from the
appropriate parameters of construction to the implementational ones. The
fact that the result of a function is permitted to be of an indefinite type
allows the user of the package to declare an object of the type without a
constraint, and initialise it using the appropriate function (the result of
which provides the constraint).

I'm pretty sure Dmitry is well aware of this technique. However, I think
many members of the ARG would feel that the proposer of a functional
construction scheme (for the next language revision) needs to demonstrate
some pretty significant advantage the proposal has over the above general
approach.

Example 1 that Dmitry gave might be rehashed thus:


package Session_Management is

   type Internet_Session(<>) is private;

   function Open (Host: in String) return Internet_Session;

   ...

private

   type Internet_Session (
         Host_Name_Length: Natural
         Traceback_Length: Natural) is
         new Ada.Finalization.Controlled with
      record
         Host_Name: String(1..Host_Name_Length);
         Traceback: ?.Node_Array(1..Traceback_Length);
         Connection: ?.IP_Connection
         ...
      end record;

end;

package body Session_Management is

   function Open (Host: in String) return Internet_Session;
   begin
      Open_Connection(Session.Connection,Host);
      declare
         Result: Internet_Session := (
            Host'Length,
            Get_Node_Count(Session.Connection),
            ... );
      begin
         ...
         return Result;
      end;
   exception
       ...
   end Open;

   ...

end Session_Management;


I've indulged myself in adding a detail -- the storage of a node
traceback -- to illustrate the idea that not just the parameters of a
constructor function can directly affect the structure of the type, but also
any arbitrary circumstances of its construction (at the time it is
constructed). I've also indulged myself in changing the names of things a
bit. These are only a minor touches.

Possibly the most relevant point is that the type (Internet_Session) is not
limited, and cannot be (because an initialisation is required and limited
types cannot be initialised).

If a limited type is required (and it probably is, realistically, for this
example), the typical technique is to make the type's implementation an
access value (referencing a totally private 'payload' type which actually
contains the relevant data, and which can be indefinite). The public
specification of the type can then be definite, so that the user can declare
an object of the type without having to initialise it, and then maybe call a
procedure to get it into a proper (initial) state (which may well involve
allocating an object of the payload type). Of course, this is usually
precisely the situation for the Ada.*_IO.File_Type types.

It could be argued that the indirection of access this causes is
inefficient, but not (or very rarely) realistically, in my opinion.

Hope this all makes sense!

--
Nick Roberts