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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,616d9205126cfe82 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Invocation of Shadowed Implementations in Ada 95 Date: 1996/09/06 Message-ID: <1996Sep6.083033.1@eisner>#1/1 X-Deja-AN: 178865637 x-nntp-posting-host: eisner.decus.org references: <1996Sep4.163433.1@eisner> x-nntp-posting-user: KILGALLEN x-trace: 842013037/28927 organization: LJK Software newsgroups: comp.lang.ada Date: 1996-09-06T00:00:00+00:00 List-Id: In article , jsa@alexandria (Jon S Anthony) writes: > In article <1996Sep4.163433.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes: > >> Although it is in the spirit of Ada syntax, it seems to me inferior >> to the Macintosh Pascal approach of: >> >> inherited Display (M); > > Which gives no idea as to what is really going on - must look elsewhere > to see what is inherited. Is it direct ancestor or remote? My direct ancestor, which may in turn, call on its direct ancestor. To skip generations seems to me as dangerous as guessing how to handle conflicts in multiple inheritance. I want to do whatever my ancestors do, plus my own operations. Presuming my ancestors are properly constructed, I will not alter their internal actions (even if Ada let me). The prime concept of inheritance seems to me that I do not have to know the detailed behaviour of my ancestors. If that were not the case, we could do it all with subroutines. Or Macros (just to be rude in C.L.A. :-). I suppose one way to achieve what I want is to use some qualifier which indicates "my direct ancestor type", but I have the feeling it is going to be more keystrokes than I had wanted. Can someone say if there is a way to specify "direct ancestor of my type" in Ada 95 ? >> in that the Ada example requires revisiting many more procedures >> if the type hierarchy is changed (unlikely for the particular >> example given, but more likely in other situations). > > Thereby preventing or at least reducing unexpected spurious behavior that > would have been very expensive to track down... I would hope for isolation of functions such that maintaining one tagged type does not require revisiting all children. Otherwise, we should be using just one package for any program. Larry Kilgallen