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!reality.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: Class-wide types algebra Date: Wed, 28 Sep 2016 15:17:17 -0500 Organization: JSA Research & Innovation Message-ID: References: <2837d915-12c8-4c23-8907-1d146d1abae7@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1475093815 4786 24.196.82.226 (28 Sep 2016 20:16:55 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 28 Sep 2016 20:16:55 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Response Xref: news.eternal-september.org comp.lang.ada:31928 Date: 2016-09-28T15:17:17-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nsfrn6$ab7$1@gioia.aioe.org... > On 28/09/2016 02:05, Randy Brukardt wrote: ... >> The problem with all forms of MI is diamond inheritance, which get much >> worse in Ada because of our strict privacy rules. > > There is no any problems with diamond inheritance and visibility. Certainly are. If one has a hidden interface with hidden overridden operations, and a later extension tries to add the same interface with different overridden operations, one of two things has to happen, both bad: (1) The interfaces are the same, so the hidden operations completely disappear. (The new extension cannot know that they ever existed, so they cannot be called from it.) Since the parent operation presumably depends on those operations, trouble is certain to ensue. (When the operations aren't overridden, then they magically become visible, which is also a problem.) (2) The interfaces are different, so one has problems in dispatching calls of figuring out which one to call. That way leads to madness. The problem here is that only (2) respects privacy at all; (1) eliminates it no matter how the conflict is resolved (the fact that the parent has a hidden interface changes the semantics of the extension even though the extension is not supposed to know or care about the interface). >> I don't think that could >> ever be solved for Ada (perhaps a new language could solve it, but not >> Ada). > > It can easily be solved once understood that inheritance may produce > conflicts to be resolved by the programmer, not by the language, which is > indeed impossible. The programmer can't resolve the conflicts unless privacy is ignored, because the programmer has no knowledge that the hidden interface is used. So why shouldn't they be able to use the same interface?? Any answer breaks privacy badly. Remember, the case in question is an extension from a private view, for which no knowledge about the implementation should escape. > Use-clauses, nesting, generic formals have *exactly* same issues there is > absolutely nothing special in inheritance. And all of those are also evil. :-) They introduce significant maintenance problems all of the time. And they don't have the problem of requiring visibility on private things to resolve the conflicts. (For all of the above, private things stay private.) Randy.