Re: Q: Endless loop by dispatching

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

On Mon, 14 Jul 2003 13:38:14 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:erm4hvsg533tp2hkhsj86tftu0s8i0ot9j@4ax.com...
>> 2. To have an ability to refer the immediate parent [and visible
>> ancestor] types. However, this feature should be carefully designed to
>> keep a way free to multiple inheritance. Something like this:
>>
>> if X in S'Class then X'Super (S) is the most specific ancestor type in
>> S'Class. For single inheritance case, it is abbreviated to S'Super.
>>
>> For tags 'Pred and 'Succ attributes should be defined to get tags
>> along a derivation path:
>>
>> T'Pred (S) is the tag of a base type in S'Class, T'Succ (S) is the tag
>> of a derived type in 'not S'Class or S' (all ancestors of S including
>> S). Constraint_Error if the result does not exist or is ambiguous.
>
>We discussed something like this when we were discussing controlling
>dispatching. However, there is a significant problem in that a type can have
>two (related) parents:
>
>     package P is
>        type NT is new T1 with private;
>     private
>        type NT is new T2 with private;
>     end P;
>
>     with P;
>     procedure Q is
>     begin
>            NT'Parent -- ???
>
>Does NT'Parent refer to T1 or T2? If it returns T2, we're breaking
>privateness (with all of the methodlogical and implementation problems that
>entails). If it returns T1, we're not really getting the right answer, and
>moreover, the result changes with visibility (yuck!).
>
>Thus, we haven't really moved forward on this.

Ah, you mean this:

package A is
   type X is tagged null record;
   type XX is new X with null record;
end A;

with A;  use A;
package B is
   type Y is new X with private;
private
   type Y is new XX with null record;
end B;

It is an interesting case. Though I see little harm if Y'Parent would
give different answers depending on scope. It would be indeed nasty if
somebody would try to call Y'Parent.Finalize, but why should one wish
a thing like that? Anyway if he would using explicit type
specification, then he could get nothing better than Y'Parent would
offer. But I agree that it is unattractive.

Probably it is worth to think how to eliminate any need in Y'Parent?
For example one could provide some sort of overriding by extension.
I.e. the bodies which would implicitly call the overriden body, as it
is manually made in Initialize/Finalize.

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