From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,da85d9aaf769b16a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!k17g2000yqb.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?= Newsgroups: comp.lang.ada Subject: Re: Generic package parameters not externally visible : what's the rational ? Date: Thu, 29 Oct 2009 05:18:26 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7e99bb5a-26a8-4ccb-b8d0-3b6882c40ebe@k17g2000yqb.googlegroups.com> References: <3084820f-4799-4555-b309-92c8ff7e2436@m16g2000yqc.googlegroups.com> NNTP-Posting-Host: 86.66.190.171 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1256818706 6822 127.0.0.1 (29 Oct 2009 12:18:26 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 29 Oct 2009 12:18:26 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: k17g2000yqb.googlegroups.com; posting-host=86.66.190.171; posting-account=vrfdLAoAAAAauX_3XwyXEwXCWN3A1l8D User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8837 Date: 2009-10-29T05:18:26-07:00 List-Id: On 28 oct, 20:07, "Randy Brukardt" 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. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ra= ndy. In return, you've just frightened me (not less) with that =93 Surely I have a feeling of confusion :-) at the idea of having a generic package with a large number of interelated formal packages =94. 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 =93 complex =94, 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