A Mother package of various data types (for sharing/interop among packages)?

How do people allow many different packages to use the same specialized data types and interoperate?

For example, suppose my project makes use of utility packages A, B, C, and each of these can operate on Ada vector containers. Furthermore, suppose C needs to operate on some results from package A and vice-versa.

Since A, B, and C are utilities type of packages, it’d be nice to have them be flexible to able to be used in different projects having different types (but no need for full-blown generic packages).

I am tempted to create a “mother of all data types package” (Mother pkg) which defines my vector containers, which types of floats to use, etc. etc.

Then write A, B, C, so they will have “with Mother”.

Different projects would have a different “Mother”, wherein the definitions may differ.

Is this a standard idiom to use? (Or is this just bad idea?)

Try to keep package instances at the library level. Then dependent packages can simply with/use them. For example, Ada standard library has instantiations with common types. E.g. Ada.Numerics.Generic_Real_Arrays is instantiated as Ada.Numerics.Real_Arrays with Float.

If your package heavily depends on a generic instance, make it a generic child of the generic package. An alternative model is having a formal generic package. Both are forms of inheritance. E.g. generic child is equivalent to a derived tagged type. Generic formal parameter is equivalent to mix-in inheritance (per access discriminant). That way you do not fix the base scalar types until very end.

P.S. As for the idea, in these sad days when people sieve junk yards for ancient DDR3 RAM modules any form refactoring and reusing generic instances will pay of. The GNAT generics model consumes incredible amounts of memory.

Typically these kinds of declarations are in the root package of the hierarchy for the project, where they are visible to all the units of the hierarchy. In general, though, most types and their operations should be declared in their own packages.

Thank you for the good “food for thought” in these posts. I appreciate both views on this and still need to ponder a bit more on how I should proceed.

It would be clearer if I was writing a “library” wherein all the sub-packages were in line with the theme of the library. But, sometimes I’d like to have a number of more general utilities in that can be mixed and matched on an as-needed basis.

This poses no problems when using standard types. But any forms of vectors, etc can complicate things for me. At any rate, my project is neither big nor important. But, it provides some learning moments.

The “Mother” package is certainly the best way to guarantee that no one besides yourself will use that code.

My rule of thumb: Use domain types if the package has algorithms for a domain; Make the package generic if it contains reusable (aka generic) algorithms.