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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!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 23:34:34 +0200 Organization: cbb software GmbH Message-ID: <56pbwdnfce0k$.5et1apcv65k9.dlg@40tude.net> References: <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net> <1oyc7ksu2lrwz.1h4pqchzcyfzt.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: evoS9sCOdnHjo0GRLLMU1Q.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: news.eternal-september.org comp.lang.ada:26594 Date: 2015-07-03T23:34:34+02:00 List-Id: On Fri, 3 Jul 2015 12:33:07 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message >> 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? > > No, but a private client can, and if you have a public type T4 derived from > T3, it would not have the function operation. > > package P2 is > type T3 is new T1 with private; > procedure Do_It (X : inT3); > private > type T3 is new T2 with null record; -- Legal! > end P2; > > with P2; > package P3 is > type T4 is new P2.T3 with C : Character; end record; -- No defined F here. This must be illegal. The compiler shall require (unless T4 is abstract): 1. That the private part of the package had a full view of P2.T3 2. F overridden there. E.g. package P2.P3 is type T4 is new T3 with record C : Character; end record; private overriding function F (...) return T4; end P2.P3; >> We have ugly executable precondition code at the declaration side. Why not >> to allow this for functions? > > I don't understand what you mean. An expression function can be given as the > overriding, but that doesn't help if you don't have the needed visibility to > see the components in question (an aggregate is only legal if no private > types are involved -- we tried to find a way to relax that for Ada 2005, but > it just got way too messy). That is the idea, to do it without visibility. When you inherit bodies of procedures you don't need visibility. You "convert" parameters (view conversion, does nothing) and call the parent's body. Similarly we could compose a body of an invisible operation. In the example above the invisible operation is F, when we derive T4 from T3 above. We do not need to know if F exists in order to say something like: if there is any primitive function returning T3 override it by adding 'A' for the component C. That would make package P3 is type T4 is new T3 with record C : Character; end record with overriding function C => 'A'; -- Imaginary syntax for automated function overriding aspect We could allow formal parameters of the aspect to be matched against parameters of overridden functions and used in the aggregate. We could allow a name of a body to initialize the type extension instead of an aggregate in order to move the mess into the package body instead of exposing it in the declaration scope, etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de