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,56dbd715fa74735a X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Mutually dependent private types Date: 1998/05/29 Message-ID: #1/1 X-Deja-AN: 357782631 References: <6k25ra$6j7$1@nnrp1.dejanews.com> <3565B105.9BFB4788@ac3i.dseg.ti.com> <356B226F.EF05E927@ac3i.dseg.ti.com> <356C8A02.44354B09@ac3i.dseg.ti.com> <356E09A1.B493FE89@ac3i.dseg.ti.com> <356F1F11.3B9A68E3@ac3i.dseg.ti.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 896481120 19396 bpr 206.184.139.132 Newsgroups: comp.lang.ada Date: 1998-05-29T00:00:00+00:00 List-Id: On Fri, 29 May 1998, John Volan wrote: > Brian Rogoff wrote: > > > > Lets explore the idea a little more though. If there were some better > > (read: more direct) support for multiple inheritance in Ada, the > > inheritance collision argument is weakened, and the workaround can become > > the blessed solution. Since an extension is being proposed anyways, > > perhaps the single inheritance restriction should be rethought. > > I'd still object to using inheritance to simulate forward type > declarations, on the grounds that it proliferates "spurious" extra > parent types, and forces programmers to do unnecessary downcasting type > conversions. A true forward type declaration doesn't introduce a > different type, it's just a different view of the same type, in the same > sense that a private type declaration and its full type declaration are > just two views of the same type. I agree on all points, but I think that your strongest argument against using inheritance for resolving forward type declarations is that they use up a valuable "line of inheritance" and that the inheritance collision problem forces reorganization of packages. I think that with better MI the withing problem could have a (only slightly inelegant) workaround, *and* there would be a bit more convenience in Ada OOP. The "withing problem" solutions you describe are only solutions to the withing problem and nothing else. There might be more bang for the language change buck in an MI extension. -- Brian