Re: Q: Endless loop by dispatching

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

Dmitry A. Kazakov wrote:

>>1) All objects of a type derived from Ada.Finalization.Controlled by 
>>default call the same version of Initialize? 
> 
> Which one version? How a public part might know that there is a
> privately declared Initialize?
> 
>>or
>>
>>2) Information hiding in effect AT THE PLACE OF THE CALL can determine 
>>which version of a subprogram is called?
> 
> For good or bad, but this was the intention, i.e. to hide Initialize
> and here you are.

Yep.

> I think that the syntax should clearly distinguish declaring a
> primitive (and thus overriding) vs. non-primitive (overloading)
> subprogram. Further, no matter how painful it could be, one should
> probably outlaw non-primitive subprograms with tagged non-class-wide
> arguments.

Actually the syntax is such that it is very difficult to have tagged 
types which are not publically tagged.  (I used to drive Tuck crazy, I 
think, during the Ada 9X process with examples using generic 
instantiations to get a type declared as "type Visible is private;" but 
which was actually a tagged type.  But let's leave those cases aside for 
a moment.  The real devilish problem occurs when the public type is tagged:

    type Public is tagged private;

    procedure Initialize(X: in out Public);

and the full declaration:

    type Public is new Ada.Finalization.Controlled with...

results in a subprogram becoming overriding in part of its scope.  That 
is what pushes for choice 1 above.  It is clear that currently 2 is 
intended by the RM, but if anyone finds themselves in this mess the 
likelihood that they will "get it right" is low.  (Remember, not even 
GNAT does.)  Also note that, in the above example, declaring Initialize 
(publicly) non-overriding is actively harmful.

I've suggested a "will override" choice for the pragma or keyword.  But 
as you say, that exposes what the programmer obviously knows is going to 
happen in the private part.  Note that there are cases where you have a 
child package containing a type derived from a private type in the 
parent package, and where you NEED for the "will override" operation to 
be public.  It is not an easy problem.

-- 

                                            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.