Re: Better control of assignment

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

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BEC12BA.E72A81EC@boeing.com...
> Nick Roberts wrote:
> >    procedure T'Construct (Object: in out T);
> >    procedure T'Destroy (Object: in out T);
> >    procedure T'Assign (Source, Target: in out T);
>
> Assignment should not be able to modify the RHS, especially as it may be
> an expression, not a variable.

Perhaps the name Assign is wrong. Maybe Copy would be better. To my mind, it
seems obvious (of course ;-) that if the RHS is a constant, this procedure
is not invoked; it is only invoked for a copy (including parameter passing
by copy (if selected)) from one variable object of type T to another. If
this does not deliver enough control, you must make the type private. For
example:

   type Odd_Counter is new Integer;
   procedure Assign_Odd (Src, Tgt: in out Odd_Counter);
   for Odd_Counter'Copy use Assign_Odd;
   ...
   procedure Assign_Odd (Src, Tgt: in out Odd_Counter) is
   begin
      if not Is_Odd(Src) then
         raise Oddness_Error;
      else
         Tgt := Src; -- inherited assignment used here by a language rule
      end if;
   end;

The idea is that an object of type Odd_Counter can only ever hold an odd
number. But nothing prevents:

   C: Odd_Counter := 2; -- oddness violation, but it will not be caught

So we must instead declare (in a package specification):

      type Odd_Counter is private;
      ...
      procedure Init (Ctr: in out Odd_Counter; Int: in Integer);
      ...
   private
      type Odd_Counter is new Integer;
      ...

And then (in the package body) we can check for oddness:

      procedure Init (Ctr: in out Odd_Counter; Int: in Integer) is
      begin
         if not Is_Odd(Int) then
            raise Oddness_Error;
         else
            Ctr := Odd_Counter(Int);
         end if;
      end;

Of course, in this case, if we want the bastion of operations pre-defined
for Integer, we must explicitly declare functions for "+", "-", "*", "/" and
so on. Too bad.

> I was thinking recently of how to provide a different implementation of
> Ada.Strings.Unbounded, and came to the conclusion that the current
> controlled-type handling of user-defined assignment is not able to
> handle the concept I had in mind. Of course, I might be wrong about
> this, and would be happy if I am.

I believe my proposal would solve the problem of the kind of implementation
of Ada unbounded strings that Jeff suggests.

--
Nick Roberts