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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 3 Nov 2009 00:25:24 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> On 31 oct, 10:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Note that a generic child package can use formals of its parent. That is
>> the case why your proposal about visibility is so important in my eyes. It
>> is an *obvious* language bug.
> 
> A step to the side, still related to your comment ...
> 
> Although related by derivation, my packages were all along each others
> (I'm experimenting, so I try many things before I choose and know
> why). I've started to rework all package, to use child package when
> possible.
> 
> It seems it saves a lot to do so : shared generic parameters, so less
> generic parameters needed for instantiation.

There is also a competitive way of "generic interface package", so to say.
That is when generic parameters are passed with another generic package
rather than directly. E.g.:

generic
   type T is private;
   with function "+" (Left, Right : T) return T;
package Generic_Interface is
   -- No own declarations, the package promotes its formal parameters
   -- to other packages
end Generic_Interface;

with Generic_Interface;
generic
   with package Parameters is new Generic_Interface (<>);
package P is
   -- Here we can define some further operations on Parameters.T and
   -- other types based on Parameters.T
end P;

> Generic package hierarchy is nicer than I previously supposed

Yes, but beware that there are *three* hierarchies:

1. one of the generic packages
2. of the instances of generic packages (you can instantiate a generic
child of generic A as a non-generic child of non-generic B)
3. of nested packages (you can instantiate within a package)

A creative use of 1-3 may create a perfect mess out of your program...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de