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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada design bug or GNAT bug? Date: Fri, 3 Jul 2015 10:02:30 +0200 Organization: cbb software GmbH Message-ID: <1oyc7ksu2lrwz.1h4pqchzcyfzt.dlg@40tude.net> References: <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: enOx0b+nfqkc2k+TNpOejg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.giganews.com comp.lang.ada:193886 Date: 2015-07-03T10:02:30+02:00 List-Id: On Thu, 2 Jul 2015 17:22:08 -0500, Randy Brukardt wrote: > "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 don't see a scenario where you could dispatch on an invisible primitive operation. First you must get into a context where you would have a view of your type having that operation. This context cannot exist without another context where the type gets derived. In that context you must have overridden the operation. Where is a problem? Is it related to MI? [But Ada does not respect privacy, when it checks inherited stuff, it does this as if in a full view of the type, which is another language bug, but still no problem.] > 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. But even if you convert to the class-wide you don't get visibility of the operation. In the scenario: type T3 is new T1 with private; private type T3 is new T2 with null record; -- Legal! a public client could not convert a T3 object to T2'Class. Could it? >>> 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!!! Yes, the hack you mean is contravariance of an out argument or result based on a guess about the type implementation (null extension). It is wrong from the strong typing POV. >> 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). No. I know you don't believe in science and proofs but still, conravariance in outputs is just wrong (under type extension). Instead of ugly hacks we better have had some delegation/body-composition methods at the declaration place to be able to tell that the overriding is basically the parent's implementation. We already allowed such stuff, e.g. procedure Foo (...) is null; We have ugly executable precondition code at the declaration side. Why not to allow this for functions? >> 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. Could you provide an example of dispatching problems you have in mind? > 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?? Honestly I never understood how that could happen. The dispatching table must be defined for any non-abstract instance. This is statically enforced, isn't it? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de