Re: A bad counterintuitive behaviour of Ada about OO

[Adam Beneschan <adambeneschan@gmail.com>]

On Tuesday, August 5, 2014 3:35:49 PM UTC-7, Victor Porton wrote:

> So now I understand what I should do. To eliminate side effects when copying 
> subobjects of Base_Object type, I should remove overriding Adjust from 
> Base_Object and define it manually for particular object types. Copy_Handle 
> then becomes unnecessary and should be removed altogether.

This seems to be on the right track.  An "Adjust" procedure that destroys data (e.g. by clearing it to 0, as you've done) is asking for trouble.  The problem, as you've found out, is that records could be copied at times when you're not expecting.  The semantics in the LRM for function calls and aggregates talk about creating anonymous objects and then copying them to their final destination, which could involve extra Adjust/Finalize calls.  Then it spells out cases where an implementation is permitted to build stuff in place (instead of building in a temporary location and copying), and avoid an Adjust/Finalize pair, and it spells out other cases where the implementation is *required* to build stuff in place.

I tried your example with two different compilers, and in both cases, the process of calling Handled_Record.From_Handle led to an Adjust call that cleared the data to 0.  This was true even after you added an explicit From_Handle for the Example_Object; your expression still called the Handled_Record.From_Handle function and that led to the Adjust call.  As an experiment, I tried rewriting From_Handle from this:

   function From_Handle(Handle: Handle_Type) return Base_Object is 
   begin 
      return (Ada.Finalization.Controlled with Handle=>Handle); 
   end; 

to this:

   function From_Handle(Handle: Handle_Type) return Base_Object is 
   begin 
      return Result : Base_Object do
          Result.Handle := Handle;
      end return;
   end; 

This caused the program to avoid calling Handled_Record.Adjust with one compiler, thus outputting the expected result, but not with the other compiler.  And neither compiler is wrong.  They're taking advantage of implementation permissions differently.

So you have to be careful when defining Adjust/Finalize for a type.  You have to make sure that whenever you call a function that returns that type, or use an aggregate or extension aggregate of that type, you have to make sure the program will work if one *or* *more* Adjust/Finalize pairs are called when moving the data around from one location to another, and you have to make sure it will work if Adjust/Finalize are *not* called.  Your original Adjust fails that test.

                                 -- Adam