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: Thu, 29 Sep 2016 13:44:56 -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 1475174674 29983 24.196.82.226 (29 Sep 2016 18:44:34 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 29 Sep 2016 18:44:34 +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:31947 Date: 2016-09-29T13:44:56-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nsii37$fl3$1@gioia.aioe.org... > On 28/09/2016 22:17, Randy Brukardt wrote: >> "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. > > It is clearly #2. What you cannot see does not exist, the old good > solipsism. Ada sometimes violates this principle, always for worse. > > There is no problem with dispatching calls so long visibility is > respected: > > 1. Where type's primitive operations are not visible you cannot dispatch > to them. ??? You can always convert an object of the type to the class-wide interface (which is legal in this scenario, even if not in the private part), and make a dispatching call. (That's the case that's a problem.). Which overriding operation do you get? If it depends on visibility, you have madness (what happens depends on where it is written - yuck). If it doesn't depend on visibility, the implementation of the original private type is going to end up with the new operations, even though those were not overridden (which is likely to break something - essentially you'd be getting the wrong copy of the interface). That of course could occur implicitly inside of a class-wide interface operation called by the private implementation (which is the reason for using interfaces in the first place), so it's a real issue. > 2. Where type's primitive operations are visible you cannot derive without > resolving the conflict between hierarchies. Sure. But that doesn't fix anything. > From this follows that you cannot use the type in the context where hidden > operations are visible! No problem, but the problem is with the type with two copies of the interface. How does the conversion to I'Class work (that conversion is implicit in calls to class-wide subprograms)? How does it chose which interface to use? The correct answer depends on what the programmer intended, and that something a compiler (or programming language) can't know. ... > Yes, when X were passed as a class-wide of another root type dispatching > to Foo would take the hierarchy of I that this root type uses. It is all > consistent. > > Y : T1'Class := ...; -- This OK, we see only private I > begin > Y.Foo; -- This dispatches on I inherited in P1, WYSIWYG > > procedure Public is > X : P2.T2; -- This is OK, we respect privateness > begin > X.Foo; -- This dispatches on I inherited in P2 Actually, this is madness. Nothing "consistent" about it. Why? Because if you move the call to some outside routine (say some other dispatching operation), the meaning changes. Which means that one can't use abstractions. Very, very bad. > The important point is that inheritance can be additive as in the case > when I is inherited once privately and once publicly. If succeeds then the > outcome is *two* hierarchies. > > You cannot forbid that altogether, which is why you see it as a problem. Well, actually we do: we forbid the private inheritance completely, because there is no consistent and sensible set of rules for what it would mean. > It is not a problem, just let it be. The implementation of two copies of the same interface would break any of the existing algorithms for implementing interfaces. (I have absolutely no idea how that could be accomplished; it would depend on how the dispatching rules were eventually worked out.) ... >> 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.) > > True, and we could do same for inheritance. Doesn't help, as noted above. Randy.