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!mx02.eternal-september.org!feeder.eternal-september.org!news.albasani.net!reality.xs3.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: Fri, 3 Jul 2015 22:11:18 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net> <1oyc7ksu2lrwz.1h4pqchzcyfzt.dlg@40tude.net> <56pbwdnfce0k$.5et1apcv65k9.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1435979479 25510 24.196.82.226 (4 Jul 2015 03:11:19 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 4 Jul 2015 03:11:19 +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: news.eternal-september.org comp.lang.ada:26598 Date: 2015-07-03T22:11:18-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:56pbwdnfce0k$.5et1apcv65k9.dlg@40tude.net... > 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. But of course that breaks privacy: T4 knows nothing about the full type of T3 or any private operations it may have. If you mean that such a derivation should *always* be illegal, well, perhaps that would have been better, but its clearly too late (it has been legal for 20+ years, there's plenty of code that depends on deriving from a non-visible private type -- Claw has a number of such types [from sibling inheritance]). >>> 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. I had suggested something on this line (but simpler): simply flag if using the default values of the extension components are enough for constructing such values (they often will be). But it didn't get much traction. You could of course submit something like the above to Ada-Comment. (Make sure to include a good problem description if you do; the problem is usually more important than the suggested solution.) At the least, it would add weight to the existing problem. Randy.