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: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!feeder.erje.net!1.eu.feeder.erje.net!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada design bug or GNAT bug? Date: Thu, 2 Jul 2015 17:22:08 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1435881890 23712 24.196.82.226 (3 Jul 2015 00:04:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 3 Jul 2015 00:04:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.giganews.com comp.lang.ada:193881 Date: 2015-07-02T17:22:08-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ykiyl6yc44or$.19365hv76bzoi.dlg@40tude.net... > On Mon, 22 Jun 2015 12:39:16 -0500, Randy Brukardt wrote: > >> We don't have a choice about allowing hidden controlling results and >> controlling access results (unless, of course, we want to abandon real >> privacy, which we're not going to do). > > If function is invisible it is, and its result is as well. Not really, because you can still dispatch to it (if the dispatching is somewhere that the private function is visible); dispatching does not respect privacy (as privacy is only a compile-time, not runtime, concept). I realize that you hate redispatching (a point that I tend to agree with you on), but it's possible, and it's needed some part of the time (maybe 10% or even less, but more than 0%), so it exists and has to be taken into account. >> The only way to avoid that problem is > > Which problem is? The operation is not visible, it cannot be called. It surely can be called where it is visible, else it isn't very useful! >> have the feature at all (which is where I would stand). > > I don't see connection to anonymous access types, the rule applies to > tagged results as well: > > package P1 is > type T1 is tagged null record; > type T2 is new T1 with null record; > function Foo return T2; > end P1; > > with P1; use P1; > package P2 is > type T3 is new T1 with private; > private > type T3 is new T2 with null record; -- Legal! This is only legal because of a hack, which I was very much against introducing. If you have an extension component, this is illegal: type T4 is new T2 with record C : Character := '1'; end record; -- Illegal!!! > end P2; I have tried to find a way to avoid this maintenance hazard (it's especially bad for mix-in generics), but I haven't gotten any traction to date. We could (if all of the extension components have defaults) automatically do this as we do for null record, but the problem is that making overriding required often detects bugs (failure to create a proper overriding). Plus the problem of incompatibility (only in obscure cases). > with P1; use P1; > package P2 is > type T3 is new T1 with private; > private > type T3 is new T2 with null record; > overriding function Foo return T3; -- ILLEGAL! > end P2; > > As such the rule does not make any sense. You shall under no circumstance > prohibit overriding of inherited operations. That's only possible if you prohibit any extensions of T3. (Otherwise, you get the dispatching problems that I noted previously, or you have to break privacy by making the derived type illegal for something that is not visible.) We've talked a bit about having such an aspect, but it is messy. To summarize: it's a bad interaction between privacy and things that require overriding (abstract subprograms follow the same rules for the same reasons). There's no real solution, else you could call abstract subprograms -- and then what?? Randy.