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!d10g2000yqh.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: Tue, 27 Oct 2009 19:19:43 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 86.66.190.2 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1256696383 8445 127.0.0.1 (28 Oct 2009 02:19:43 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 28 Oct 2009 02:19:43 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d10g2000yqh.googlegroups.com; posting-host=86.66.190.2; 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:8822 Date: 2009-10-27T19:19:43-07:00 List-Id: On 27 oct, 23:19, "Jeffrey R. Carter" wrote: > Then C clearly has a dependency on this 4th pkg (shall we call it D?), an= d that > dependency should be made explicit, by including "with D;" on C. While both origin are equally legitimate, and this is not only the case with generics. This make me thing its the same kind of type matching by name (or declaration) and type matching by structure. Here, we could say than the origin means something. As a concrete image, let say the type in its first declaration place, has some comments attached to it. Ok. Then, a package as a formal parameter, with some comments attached to this parameters. Then, the parameters is associated to the defined type. Here, the presence of comments stands for a meaning, and the fact that some comment may be associated to the type at the place where it is a formal parameter, shows that using one or the other origin, may not means the same thing. If I refer to A.C, this may not mean the same as if I refer to B.C, even if C is the same in both place. After all, the generic parameter of a package, is one location, a fixed location, and the type used to instantiate the package, may not be so much clearly fixed (I apologize if my word does not seems very clear, I'm trying to express a though). If I refer to A.C, I mean something, if I refer to B.C, I may mean something else, and the difference may have multiple cause (clarity, logic, requirement, style, etc). I take long to talk about and does not hesitate to say a lot about details, because I'm currently thinking about what conventions I should use, what patterns and overall strategies for this and that. And I would like to work at it the sooner, rather than to have to come back to it too much late (I'm testing on a little sample application with about 40 small packages, most of which are generics, and spend a lot of time to rewrite this and that, re-read all to see if it seems accessible and readable, easy to use, well glued, etc). > But Ada allows a generic to reference the unknown generic parameters of i= ts > formal package parameters. See ARM 12.7. I did not knew about it, I will look at it tomorrow. Thanks for the point. On 28 oct, 00:34, Robert A Duff wrote: > > Indeed, I find that it makes "perfect sense" for them not the visible: = they > > are not part of the package that gets instantiated. That's clear from t= he > > syntax (they're outside the package). > > I've always found that syntax odd, for what it's worth. > Part of the declarative region of the generic package > comes before its name. The same for me, I have never really feel at ease with this package name not coming at the first place (probably another thing from the beginning of the long history of Ada). About the previous assertion, saying =93 they are not part of the package that gets instantiated =94, I sincerely do not understand this assertion. Where are they if they are not part of the package ? If they are given as parameters, they are injected in the package. But right a few minutes ago, I was thinking that is may be finally better to be able to hide something there. Perhaps peoples who were talking about protecting type privacy, were thinking about a formal parameter used in the private part of the package only. When it is (this may not always be so much strange as it seems, to give formals parameters which are only used in private part), it is better to not make these visible from the outside. Providing this is a good answer, then the actual is so just the best, because it allow to show or hide at the discretion of the author (the language does not impose anything there, except it hides by default, and that's finally a good fact).