Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!bionet!agate!ucbvax!elma.epfl.ch!madmats
From: madmats@elma.epfl.ch (Mats Weber)
Newsgroups: comp.lang.ada
Subject: Overloading of assignment
Message-ID: <881125130910.218003ab@elcc.epfl.ch>
Date: 25 Nov 88 12:09:10 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 64


The question of what an overloaed assignment procedure should look like still
remains:

  variant A:

  procedure ":=" (OBJECT : out SOME_LIMITED_TYPE;
                  VALUE  : in  SOME_LIMITED_TYPE);

  variant B:

  procedure ":=" (OBJECT : in out SOME_LIMITED_TYPE;
                  VALUE  : in     SOME_LIMITED_TYPE);

The problem with variant A is that if SOME_LIMITED_TYPE has subcomponents that
are of an access type, then no garbage collection can be performed on OBJECT
before assigning it its new value, because OBJECT cannot be read inside ":=".

The problem with variant B is that it cannot be used for the initialization
of an object (unless SOME_LIMITED_TYPE is an array or record type) because the
actual parameter for OBJECT must have a defined value before the use of ":="
(otherwise the program is erroneous). Consider the following example:

   package ADT is

      type T is limited private;

      procedure ":=" (OBJECT : in out T; VALUE : in T);

      function TO_T (N : INTEGER) return T;

   private

      type T is range 0..1000;

   end ADT;

   with ADT;
   procedure P is

      X : ADT.T;

      use ADT;

   begin
      X := TO_T(7);    -- this call of ":=" is erroneous because X
   end P;              -- is undefined.


Variant A is better if SOME_LIMITED_TYPE is a scalar type,
variant B is better if SOME_LIMITED_TYPE is an array or record type,
both variants work with access types as these always have the initial value
null.

Personally, I think the rules on assignment in Ada cannot be changed if
upward compatibility is to be acheived.

Mats Weber
DI-LITh-EPFL
Swiss Federal Institute of Technology
1015 Lausanne
Switzerland

e-mail : madmats@elma.epfl.ch