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.63.215 with SMTP id m206mr8515760ioa.28.1513524360665; Sun, 17 Dec 2017 07:26:00 -0800 (PST) X-Received: by 10.157.32.78 with SMTP id n72mr673942ota.12.1513524360424; Sun, 17 Dec 2017 07:26:00 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!g80no599358itg.0!news-out.google.com!b73ni2272ita.0!nntp.google.com!g80no599356itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 17 Dec 2017 07:26:00 -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: <5b32a99e-04e5-4adb-8b42-88e485570641@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <83982113-349e-4443-b457-e63d749ad42a@googlegroups.com> Subject: Re: Full view of a private partial view cannot be a subtype From: Jere Injection-Date: Sun, 17 Dec 2017 15:26:00 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:49503 Date: 2017-12-17T07:26:00-08:00 List-Id: On Tuesday, December 5, 2017 at 3:12:43 PM UTC-5, Randy Brukardt wrote: > "Jere" wrote in message > > 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. > > If you control the entire design of the type hierarchy, the best way to do > this is to put "Really_Dangerous_to_Call" into the private part of the root > operation, and declare the child types in child packages. Then, the child > types can call the routine but clients cannot. (An added advantage is that > Really_Dangerous_to_Call can be dispatching in such a design.) > > > Randy. Thanks! I think that still leaves me with the same issue. All I really want out of the client package is that it implements subtypes and renames of the hidden package. I don't really want to derive or extend or even do composition if I have to because it leads to a lot of code that is easy to mistype, difficult to parse through and read later on, and possibly add overhead (not normally an issue, but this is a low level core library for me so I at least have to consider my implementation some). All for no readability benefit (and actual detriment to reading). my assertion is that: subtype Thing is Core_Pkg.Thing; procedure Do_Something(The_Thing : in out Thing) renames Core_Pkg.Do_Something; is easier to both maintain and read than: type Thing is new Core_Pkg.Thing with null record; procedure Do_Something(The_Thing : in out Thing); ... procedure Do_Something(The_Thing : in out Thing) is begin Core_Pkg.Thing(The_Thing).Do_Something; end Do_Something; and: type Thing is record Parent_Thing : Core_Pkg.Thing; end record; procedure Do_Something(The_Thing : in out Thing); ... procedure Do_Something(The_Thing : in out Thing) is begin The_Thing.Parent_Thing.Do_Something; end Do_Something; The first option completely conveys how I want to implement it while the latter two options require additional code that adds no extra readability and gives the reader/maintainer even more to parse through (additional files and additional code) in order to determine what is going on. Furthermore it opens the maintainer up to more mistakes if this needs to be done for a lot of functions (20+). Additionally, the complexity in both reading and maintainability only gets worse if the operation signatures use multiple types that all need this same treatment. I don't mind writing the extra stuff if it gives me more readability or safety, but in this case it just feels like I am trading up readability for more writing, which I don't like doing. I like things easy to read. You're correct in that using private packages hides the Really_Dangerous_To_Call uses, but I'm still left with the original issue that I am making my code more unreadable to do so. I know that, based on this email chain, the latter two are my only options. I was just hoping there was a third option involving encapsulation of subtypes. Out of the two later approaches, composition fairs much better in readability (and possible overhead). It just has much less readability than the subtype method. I can try to give better specifics if that helps. I try to avoid that in C.L.A though as it ends up sending people down paths that are tangential, and my original question gets lost. Also it helps to keep things simple so that people can more easily help/answer. I realize the onus is on me to be better at explaining what I need though. So if you need better specifics, I can do better to provide them.