Re: Visibility issue

[Simon Wright <simon@pushface.org>]

Daniel <danielnorberto@gmail.com> 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.