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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Preventing private procedure visibility being made public through extension Date: Mon, 22 May 2017 16:12:10 -0500 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1495487531 3025 24.196.82.226 (22 May 2017 21:12:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 22 May 2017 21:12:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:46853 Date: 2017-05-22T16:12:10-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ofq943$14v4$1@gioia.aioe.org... ... > ---------------------------------- > The actual problem you have is parallel types hierarchies. You want to > derive tied instances of Base_Type'Class and Base_Param'Class. > > Base_Type ----- Base_Param > | | > Derived_Type -- Derived_Param > > This requires > > 1. Full multiple dispatch > 2. Dispatch constrained to certain combinations (parallel hierarchies) > > This is not supported in Ada (or in any other OO language I am aware of) Right. Having investigated this, it seems impossible to support in any language that is intended to support LSP (which is the backbone of OOP). The basic problem is dispatching. In Ada terms, you have a call: Something (Classwide_Obj, Othertype_Obj); where Classwide_Obj is of Root'Class. Now, the problem is that the other (usually untagged) parameter is of the wrong type for the routines that you dispatch to. There are various ways you can fix this dynamically (for instance, as you noted, with multiple dispatch), but there is no way to have any static typing in these cases. But the entire point of doing a "co-derivation" is to get static typing, so you're doing a lot of work for very little gain. Co-derivation probably could be made to work for untagged types (as they don't have dispatching to worry about), but it's unclear that enough benefit would arise. Anyway, this is an agenda item for the ARG, but unless someone has an idea that hasn't been considered to date it isn't going anywhere. Randy.