Re: Generic package parameters not externally visible : what's the rational ?

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

On 27 oct, 23:19, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> Then C clearly has a dependency on this 4th pkg (shall we call it D?), and that
> dependency should be made explicit, by including "with D;" on C.
While both origin are equally legitimate, and this is not only the
case with generics.
This make me thing its the same kind of type matching by name (or
declaration) and type matching by structure. Here, we could say than
the origin means something. As a concrete image, let say the type in
its first declaration place, has some comments attached to it. Ok.
Then, a package as a formal parameter, with some comments attached to
this parameters. Then, the parameters is associated to the defined
type. Here, the presence of comments stands for a meaning, and the
fact that some comment may be associated to the type at the place
where it is a formal parameter, shows that using one or the other
origin, may not means the same thing. If I refer to A.C, this may not
mean the same as if I refer to B.C, even if C is the same in both
place. After all, the generic parameter of a package, is one location,
a fixed location, and the type used to instantiate the package, may
not be so much clearly fixed (I apologize if my word does not seems
very clear, I'm trying to express a though). If I refer to A.C, I mean
something, if I refer to B.C, I may mean something else, and the
difference may have multiple cause (clarity, logic, requirement,
style, etc).

I take long to talk about and does not hesitate to say a lot about
details, because I'm currently thinking about what conventions I
should use, what patterns and overall strategies for this and that.
And I would like to work at it the sooner, rather than to have to come
back to it too much late (I'm testing on a little sample application
with about 40 small packages, most of which are generics, and spend a
lot of time to rewrite this and that, re-read all to see if it seems
accessible and readable, easy to use, well glued, etc).

> But Ada allows a generic to reference the unknown generic parameters of its
> formal package parameters. See ARM 12.7.
I did not knew about it, I will look at it tomorrow. Thanks for the
point.

On 28 oct, 00:34, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> > Indeed, I find that it makes "perfect sense" for them not the visible: they
> > are not part of the package that gets instantiated. That's clear from the
> > syntax (they're outside the package).
>
> I've always found that syntax odd, for what it's worth.
> Part of the declarative region of the generic package
> comes before its name.
The same for me, I have never really feel at ease with this package
name not coming at the first place (probably another thing from the
beginning of the long history of Ada).

About the previous assertion, saying “ they are not part of the
package that gets instantiated ”, I sincerely do not understand this
assertion. Where are they if they are not part of the package ? If
they are given as parameters, they are injected in the package.

But right a few minutes ago, I was thinking that is may be finally
better to be able to hide something there. Perhaps peoples who were
talking about protecting type privacy, were thinking about a formal
parameter used in the private part of the package only. When it is
(this may not always be so much strange as it seems, to give formals
parameters which are only used in private part), it is better to not
make these visible from the outside. Providing this is a good answer,
then the actual is so just the best, because it allow to show or hide
at the discretion of the author (the language does not impose anything
there, except it hides by default, and that's finally a good fact).