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

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

On 27 oct, 22:36, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> One possible rationale is:
>
> In order to reference the generic parameters from the instance, you have to have
> visibility of the instantiation. If you have visibility of the instantiation,
> then you have visibility of the generic actual parameters used in the
> instantiation. Therefore, you do not need visibility of the generic parameters
> from the instance, so why complicate the language by providing it?

After that, I will then try to give a view of the other hand :

One good reason to miss it, is when a package A has another package B
in its formal parameters and this formal package parameter (B) is it
self generic, and A needs to use some type which were given to
instantiate the package B. This is an example case where the parameter
which were used to instantiate a package, are not accessible from a
point they are needed (if P instantiated B, of course P has access to
parameters used to instantiate B, but this does not help A, it if ever
itself also need these).

More about this latter point : it may be possible, to just give to A,
the same type, but if A has let say, two of three package in its
formal parameters, then, the number of generic parameter may increase
a bit too much, at the cost of readability or at the cost of easy of
use. Using such redundancies sometime, in the opposite, help
readability or is useful when it recall something explicitly, but
sometime, when it is too much, it breaks readability and comes with a
feeling of confusion.

To come back to the first point : one other good reason apart of a
generic package having another generic in its parameters, is when a
generic package B may also be instantiated in a package A, which will
then be use in another package C, which does not have direct access to
the parameters used to instantiate the package (let say it was in a
third package which A deeply rely on one, but not C). Then, one of the
more natural way to access these, if ever needed for other stuff in C,
is the generic package instance B itself.


Randy Brukardt Wrote :

> And changing it surely would be incompatible, at the very
> least with use-visibility

That's an interesting point indeed. I did not though about it at first
sight, because I never Use.