Re: Q: Endless loop by dispatching

["Robert I. Eachus" <rieachus@attbi.com>]

Dale Stanbrough wrote:

> Does it cover the opposite where due to a typo you haven't overridden a 
> subprogram?

That is the major impetus behind it.  If you think you are overriding, 
and the compiler doesn't, there is an error.  It can be in your 
understanding of the situation, the compiler's understanding, or just be 
a typo.

The problem is, as I said is WHERE the declaration is overriding. I 
created an example:
--------------------------------------------------------------------------

Now my head really hurts!  Are you saying that the original derived 
Finalize declaration really can't be overridden and that in this case 
(or in this case with Finalize spelled right) dispatching still calls 
the implicit operation?  I hope not, and that this is just semantics.

Let me create a better example (in current Ada):

  with Ada.Finalization;
  package Root is
    type Root_Type is tagged private;
    function Value (Object : Root_Type) return Integer;
    procedure Set (Object : in out Root_Type; Value: in Integer);
  private
     type Root_Type is new Ada.Finalization.Controlled with record
       Init_Case: Integer := 3; end record;
    procedure Initialize (Object : in out Root_Type); -- 1
    -- Finalization hidden in private part to since Controlled is
    -- hidden.
  end Root;

  package body Root is
    function Value (Object : Root_Type) return Integer
    is begin return Object.Init_Case; end Value;

    procedure Set (Object : in out Root_Type; Value: in Integer) is
    begin Object.Init_Case := Value; end Set;

    procedure Initialize (Object : in out Root_Type) is
    begin Object.Init_Case := 1; end Initialize;

  end Root;

  with Root;
  package Leaf is
    type Derived_Type is new Root.Root_Type with null record;
    -- derived type is known to be tagged but not controlled.
    procedure Initialize (Object : in out Derived_Type); -- 2
    -- Tucker says this is not overriding, right?
  end Leaf;

  package body Leaf is
    procedure Initialize (Object : in out Derived_Type)
    is begin Set(Object, 2); end Initialize;
  end Leaf;

  with Leaf;
  with Ada.Text_IO; use Ada.Text_IO;
  procedure Sample is
       Obj : Leaf.Derived_Type; -- Which Initialize gets called?
  begin
    case Leaf.Value(Obj) is
    when 1 => Put_Line(" Root.Initialize Called.");
    when 2 => Put_Line(" Leaf.Initialize Called.");
    when 3 => Put_Line(" No initialization!");
    when others => Put_Line(" I give up!");
    end case;
  end Sample;

E:\Ada\Test\AI-218>sample
  Leaf.Initialize Called.

At least GNAT agrees with me. ;-)  Seriously I think that Tucker may be 
correct, "by the book."  But to not be able to declare Leaf.Initialize 
as overriding defeats the whole point.  Sigh.  So now even if we adopt 
my solution or the new syntax, we still have to change 7.3.1 to get the 
definition of overriding to agree with the (to me) commonsense definition.

------------------------------------------------------------------------

As you will see if you read the whole discussion, other compilers do NOT 
agree with me.  For some reason Tucker's compiler agrees with him. ;-) 
And of course, I haven't submitted this as a bug against GNAT until the 
AI as a whole is resolved.

Incidently I am posting this here to give the spectators a view of what 
is going on.  This is a hard and non-trivial issue.  It might be nice if 
in the final version, declaring Leaf.Initialize to be overriding could 
"pierce the privateness" and cause it to be so.  I went out of my way in 
writing this code, so that there is no location where Leaf.Initialize is 
overriding.  (At least as Tucker and the RM seem to currently define 
overriding.)  But as I say, the (very hard) issue is to come up with a 
way to do add the overriding keyword so that it helps users overall. 
The "little test" of putting the overriding declaration in the right 
place is a potential huge pain to users. (If Leaf was a child of Root, 
then Initialize would be overriding in the body and in the private part 
of Leaf if there was one.  Obviously in that case declaring 
Leaf.Initialize as non-overriding helps no one.)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.