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

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

On 28 oct, 20:07, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Surely I have a feeling of confusion :-) at the idea of having a generic
> package with a large number of interelated formal packages. That sounds a
> new way to create unmaintainable spagetti code (gotos aren't the only way to
> make things impossible to understand). That's irrespective of how the
> formals on the outer package are named.
>
>                                    Randy.

In return, you've just frightened me (not less) with that “ Surely I
have a feeling of confusion :-) at the idea of having a generic
package with a large number of interelated formal packages ”. Sounds
to me like if you attempted to make me understand I'm making a *big*
design mistake.

May I say gotos are sometime considered not so much evil, but it is
not the spot here

The same coupling between formal packages do exist, even if it's less
visible, with other packages because they are not generic. I attempt
an example : let say we want a package whose intent is to search
matches of some kind of patterns in strings. We feel its something
which is finally somewhat universal, and we decide to make it a
generic package, working on arrays of discrete type items. So instead
of a package working on strings, we create a generic package, with a
formal type parameter, which will be instantiated with
Standard.Character or Standard.Wide_Wide_Character for the initial
purpose. Then, we later wish some helpers to log statistics on
patterns and sequences which matched each others (an example, do not
expect it to be clearly useful at first sight, just imagine it is
useful to someone). This helper package must work with the same type
of data the pattern-matching package use. It will have a pattern-
matching package as one of its formal parameters, and for clarity, we
may add the discrete type to its parameters as well, to clearly show
they have this type in common. Imagine now (my own imagination has
exhausted at this point, so imagine what you want), we have a second
helpers, which is related to the first package the same the other
helper package is, and again another package, which has this time,
dependencies to the two helpers package.

This may seems “ complex ”, but this is not more than any other stuff
of the same area, like data flow, code flow or the like. If relations
and dependencies are clear and coherent, what is like spaghettis
here ?

Another advocating based on a comment after the previous example :
with non-generic, you would just see multiple packages each holdings a
reference to Standard.Wide_Wide_Character, thus you will not feel
there are coupled, but just related to Standard.Wide_Wide_Character.
There, as they are all generics, you see them all depending each
others, to be sure they all use some one type in common. This seems
complex, because a dependency is clearly reported and stated, while
this is not clearly stated with non-generic (this would just be fact
someone may notice after analysis), but relations are finally still as
much complex, and they are the same in both case (generic, and non-
generic case).

I do not mean you comment is wrong, I just attempt to reply and
advocate an view on the situation.

If I'm surely wrong on the long time, I want to know before I discover
it myself after a (too much) long time