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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.10.203 with SMTP id 72mr16099752iok.8.1512478596137; Tue, 05 Dec 2017 04:56:36 -0800 (PST) X-Received: by 10.157.1.175 with SMTP id e44mr823883ote.1.1512478595945; Tue, 05 Dec 2017 04:56:35 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!193no1789686itr.0!news-out.google.com!s63ni4666itb.0!nntp.google.com!i6no3495283itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 5 Dec 2017 04:56:35 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.208.22; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.208.22 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5b32a99e-04e5-4adb-8b42-88e485570641@googlegroups.com> Subject: Re: Full view of a private partial view cannot be a subtype From: Jere Injection-Date: Tue, 05 Dec 2017 12:56:36 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:49377 Date: 2017-12-05T04:56:35-08:00 List-Id: On Monday, December 4, 2017 at 3:49:54 PM UTC-5, Randy Brukardt wrote: > "Jere" wrote in message > ... > > package New_Type1 is > > subtype Instance is Base.Instance; > > procedure Operation(Object : in out Instance); > > > > private > > > > procedure Operation(Object : in out Instance) renames Base.Operation; > > end New_Type1; > > > > (NOTE: is there a better way to do this?) > > No, no better way yet, but maybe (large maybe here) in Ada 2020. (I'm > leaving out all details because none have been determined yet and perhaps > never will be for Ada 2020.) Sounds intriguing! > > > This is all well and good, but sometimes while I as an implementer > > want this kind of relationship, I don't necessarily want to expose > > that relationship outside the private section of a package. Here I > > run into a problem as I cannot (as far as I can tell) do: > > > > package New_Type2 is > > type Instance is tagged limited private; > > procedure Operation(Object : in out Instance); > > private > > subtype Instance is Base.Instance; > > This is illegal; a private type has to be completed with a full type, not a > subtype. (If you have a compiler that is allowing this, it is confused...) Yep, that was my comment. Basically I have a low level package that is used to create many higher level, more client friendly packages: generic type Input_Type(<>); with procedure Really_Dangerous_To_Call(Object : Input_Type); Value : Integer; package Low_Level_Package type My_Type is private; type Numeric_Type is ; function Client_Friendly_Procedure (Object : My_Type) return Numeric_Type; private ... end Low_Level_Package; and I want to use it to make some more client friendly versions. The procedure, Really_Dangerous_To_Call, isn't meant to be called directly for a client. It is meant to be used to setup implementations behind the client packages. At current my choices seem to be: subtyping: generic type Input_Type is limited private; package High_Level_Package procedure Client_Please_Do_Not_Call(Object : Input_Type); package I_Really_Wanted_To_Hide_You is new Low_Level_Package (Input_Type => Input_Type, Really_Dangerous_To_Call => Client_Please_Do_Not_Call, Value => ); subtype My_Type is I_Really_Wanted_To_Hide_You.My_Type; subtype Numeric_Type is I_Really_Wanted_To_Hide_You.Numeric_Type function Client_Friendly_Procedure (Object : My_Type) return Numeric_Type renames I_Really_Wanted_To_Hide_You.Client_Friendly_Procedure; end High_Level_Package; which exposes operations and values I do not want to expose in a more client friendly package. Currently in Ada there isn't a way that I have found to use subtyping for this in a private manner. Instead I either need to bite the bullet and expose those details (ugh), or I need to use extension or composition, of which composition is less noisy, but both will end up requiring some noisy code and possibly extra unnecessary overhead (depending on how the type conversions work out). So here the tradeoff appears to be readability vs overhead, which I don't feel it needs to be in this case, but I haven't found a good Ada building block that gives me both. > > At (1), you are renaming the operation inherited from Base.Instance. That > operation isn't visible to clients, only within this package. And it has the > correct types. > > The main use for a "squirrelling" rename is to be able to call the original > operation in a overridden operation: > > package New_Type4 is > type Instance is new Base.Instance with record ... end record; > -- Operation is inherited here, with the profile: > --procedure Operation (Object : in out Instance); > private > > procedure Original_Operation(Object : in out Instance) renames > Operation; -- (1) > overriding > procedure Operation (Object : in out Instance); > end New_Type4; > > The declaration at (1) allows the body of Operation to call the body of > Base.Operation (but with the proper types). > > Randy. This is an option I use sometimes. In this case I was hoping to keep all the interfaces named the same. I typed this up hurriedly, so I apologize if I made a typo. I hope the meaning is conveyed better though.