Re: Q: Endless loop by dispatching

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Mon, 21 Jul 2003 18:51:34 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> Another evil is that constructors/destructors are exposed as "normal"
>> operations having some special semantincs attached to them *depending*
>> on the context. This also won't work. The word "Initialize" suddenly
>> becomes some very special for the compiler in the private part, being
>> just a name in the public one. If it were just a procedure Foo, one
>> could probably live with it.
>
>Initialize (and for that matter Ada.Finalization) is just a convenient 
>scapegoat to use in examples.  The problems can occur with any 
>predefined operations of a tagged type.

Yes, but for Initialize/Finalize the consequences are usually
catastrophic. This is why I would prefer either a special syntax (C++
way), or a more general approach with overriding by extension. Which
can be later well re-used:

1. for user-defined aggregates, if they come;
2. for overriding entry points of tagged tasks, if ...;
3. for overriding operations of tagged protected objects, if ...;

>(But there is this one package 
>in the RM that declares tagged types which is why it tends to get used 
>in examples.)
>
>> IMO it should be illegal with any pragma:
>> 
>> package A is
>>    type Public is tagged private;
>>    procedure Initialize(X: in out Public);
>> private
>>    type Public is new Ada.Finalization.Controlled with...
>>       -- Error public and private views are incompatible!
>> end A;
>> 
>> It could be made legal only if primitive operation disallowing were
>> supported:
>
>That is an interesting approach.  I can't see justifying disallowing it 
>entirely, but saying that:
>
>    not overriding procedure Initialize(X: in out Public);
>    -- or whatever syntax is chosen
>
>becomes illegal in the private part might be a good idea.  At least it 
>prevents the misleading use of the keywords.  If we still have "may 
>override" and add my "will override" then the programmer gets to choose 
>what to say publicly, which is nice, and still get the advantage of the 
>compiler checking his assertions.
>
>> A more interesting case:
>> 
>> package AA is
>>    type Public is tagged private;
>> private
>>    type Public is new Ada.Finalization.Controlled with...
>> end AA;
>> 
>> with AA;  use AA;
>> package B is
>>    type Public_Public is new Public with private;
>>    procedure Initialize(X: in out Public_Public);
>>       -- This is legal. B knows nothing about Public's origin
>>       -- so it cannot misuse it
>> private
>>    type Public_Public is new Public with ...
>> end B
>> 
>> package AA.C is
>>    type Private_Public is new Public with private;
>>    procedure Initialize(X: in out Public_Public);
>>       -- This is an error. C knows Public's private, so
>>       -- its private part is illegal
>> private
>>    type Private_Public is new Public with ...
>> end AA.C
>
>Change Private_Public to new Public_Public with private and you will 
>begin to understand the problem.  AA.C.Initialize would override 
>B.Initialize everywhere, but would only override AA.Initalize, assuming 
>that there is one, in some areas of its scope.

If you mean this:

with B; use B;
package AA.D is
   type Private_Public_Public is new Public_Public with ...;
end AA.D;

then it should be again a compile error, because AA.C "knows" that
Public_Public has a private Initialize which collides with the public
one. The rule is simple - there should be no way to create a context
where both versions of Initialize could be visible.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de