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.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.vgGlwuxQpjN0s/naYp4vQQ.user.gioia.aioe.org!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Visibility issue Date: Fri, 18 Sep 2020 09:05:37 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <27269975-58eb-407b-98ca-344bee6894d2n@googlegroups.com> <28481dfd-7127-4106-bcfd-f085ffbf228fn@googlegroups.com> <574318ce-0624-4893-8718-37f2e97736b7n@googlegroups.com> NNTP-Posting-Host: vgGlwuxQpjN0s/naYp4vQQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) X-Notice: Filtered by postfilter v. 0.9.2 Cancel-Lock: sha1:Q04KOA1+HOziHgGKAvbGNEyHCQ8= Xref: reader02.eternal-september.org comp.lang.ada:60189 List-Id: Daniel writes: > ok Lets try to fit this requirement: >>"There will be one or more internal packages not visible to users >> where information is created. Preferably not in API hierarchy" > Let's ignore for now "why" this requirement and how reasonable is > it. For example lets think for that the information comes from a data > link implemented in other packages different to API. I can't ignore this "requirement" (well, I can ignore it in practice, because it's just an intellectual puzzle that someone (an educator?) has dreamt up). A customer who says "we would give preference to Ada-based solutions, because we believe they will be better" is being reasonable. Of course, it may be that you have a customer who knows how to do this in C++, and is challenging you to replicate that solution in Ada. > In your example, all data is generated and processed within API > packages, but the requirement obligates the data generated outside > have to be send to users through API elements. (API just process it, > but not generate it) Come on, it's only a toy example! The private child packages can do anything that's needed, communicate with databases,, AI, ... And, to reiterate what Dmitry says, (a) private child packages are *not* part of the API, (b) my point in using them was to show that they are the way to get access to the private parts of the public API.