From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fba93c19bb4e7dbd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-15 01:46:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.ems.psu.edu!news.litech.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!newsfeed.r-kom.de!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Q: Endless loop by dispatching Date: Tue, 15 Jul 2003 10:47:14 +0200 Message-ID: References: <3F0ED2C8.6080409@snafu.de> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1058258763 10453449 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40283 Date: 2003-07-15T10:47:14+02:00 List-Id: On Mon, 14 Jul 2003 13:38:14 -0500, "Randy Brukardt" wrote: >"Dmitry A. Kazakov" 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