From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.0 required=3.0 tests=BAYES_40,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:ac8:168c:: with SMTP id r12mr21539193qtj.221.1600286994101; Wed, 16 Sep 2020 13:09:54 -0700 (PDT) X-Received: by 2002:a0c:a162:: with SMTP id d89mr25819906qva.28.1600286993823; Wed, 16 Sep 2020 13:09:53 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 16 Sep 2020 13:09:53 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=92.56.166.72; posting-account=C8J7NQoAAAD_ybGY7--QIRi6KpLjoH1Z NNTP-Posting-Host: 92.56.166.72 References: <27269975-58eb-407b-98ca-344bee6894d2n@googlegroups.com> <28481dfd-7127-4106-bcfd-f085ffbf228fn@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <574318ce-0624-4893-8718-37f2e97736b7n@googlegroups.com> Subject: Re: Visibility issue From: Daniel Injection-Date: Wed, 16 Sep 2020 20:09:54 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:60172 List-Id: El mi=C3=A9rcoles, 16 de septiembre de 2020 a las 17:05:07 UTC+2, Dmitry A.= Kazakov escribi=C3=B3: > On 16/09/2020 16:35, Daniel wrote:=20 > > El mi=C3=A9rcoles, 16 de septiembre de 2020 a las 12:58:58 UTC+2, Dmitr= y A. Kazakov escribi=C3=B3:=20 > >> On 16/09/2020 12:23, Daniel wrote:=20 > >>> El mi=C3=A9rcoles, 16 de septiembre de 2020 a las 9:14:23 UTC+2, Dmit= ry A. Kazakov escribi=C3=B3:=20 > >>=20 > >>> Let's try to set and construct all hidden part details from Internal = side, not from user side.=20 > >> [...]=20 > >>=20 > >> Assuming "internal side" means "implementation side", this is in clear= =20 > >> contradiction with the code you posted. Your package Internal is=20 > >> implementation and thus must be able to access whatever implementation= =20 > >> details it needs.=20 > >>=20 > >> Otherwise the API must provide means of construction. [Must be done=20 > >> anyway in order to ensure the contract of Handle, provided default=20 > >> initialization does not do that.]=20 > >=20 > > Then, I assume there is not a clear solution in Ada due to my imposed r= equirements > Why? It is not in requirements, it is solely your design.=20 >=20 > I see no reason why the package Internal.CallbacksPool must be limited=20 > to the public API. But I also see no reason why public API does not=20 > provide means to construct fully functional handles. > > So if the "Implementation side" needs all details, > Implementation holds all details, per definition of implementation. > > I only think in two options :=20 > > 1.- Put the details of implementation in a children package in the API = hierarchy, and try to explain users to don't "with it". I can try to make i= t really empty in the public part of the children package and only put what= its needed for the implementation. > 1. Children packages can be private. You cannot with them from outside.= =20 >=20 > 2. Nothing forces you to put anything into the public part of a public=20 > child package. With-ing it would expose nothing.=20 >=20 > 3. Packages can be nested and put into bodies of other packages. These=20 > will not exist as library packages for the user.=20 >=20 > 4. Packages can have separate bodies if become too large. These bodies=20 > are all private.=20 >=20 > There are lots of ways to make things private in Ada.=20 >=20 > [There are a few cases when privacy does not work in Ada, but none of=20 > those are related to your problem] > > 2.- Take out the details from "API hierarchy packages" to the "Implemen= tation package hierarchy" and make visible everything I need in the "API si= de", and try also to explain users to don't use them. > There is absolutely no need doing this. > --=20 > Regards,=20 > Dmitry A. Kazakov=20 > http://www.dmitry-kazakov.de OK, I think maybe I'm not explaining the problem precisely. Before going fo= r the first option I'm curious to explore and to learn how can be done usin= g the second option. Let me start from scratch. I want to make a design that fits the next requirements/limitations: -There will be just one API package hierarchy that users can "with it" -This API hierarchy will define a callback procedure type with a tagged typ= e as an argument -This tagged type argument of the callback procedure template will be defin= ed in API hierarchy including a set of procedures in order to access and c= onvert information to users. -There will be one or more internal packages not visible to users where inf= ormation is created. Preferably not in API hierarchy -The information will be passed to users with the callback procedure they a= lready wrote and they already set using API. - Internal information data types must be decoupled from API data types. - Usually, information that is generated internally is bigger than the user= needs to know, so API tagged type argument of the callback procedure needs= to convert it =C2=BFWith these requirements/limitations, which design approach you think = is better to start the design?