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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no 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,ASCII Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!u-picardie.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Generic package parameters not externally visible : what's the rational ? Date: Tue, 27 Oct 2009 16:08:09 -0500 Organization: Jacob Sparre Andersen Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1256677691 6919 69.95.181.76 (27 Oct 2009 21:08:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 27 Oct 2009 21:08:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:8812 Date: 2009-10-27T16:08:09-05:00 List-Id: "Robert A Duff" wrote in message news:wcciqe26w5q.fsf@shell01.TheWorld.com... > "Hibou57 (Yannick Duch�ne)" writes: > >> Still the time for my two cents of the day : parameters of generic >> packages are not externally visible. I use to read in a few places on >> the web, this is so to preserve type privacy, but without any examples >> which could illustrate this view. >> >> What's the rational behind this ? > > I don't think there is any rationale. It makes perfect sense > for them to be visible, but they're not. I guess it was just > a minor mistake in Ada 83, and it's never been thought important > enough to fix in later versions. I don't see any way in > which this rule "preserves type privacy". I'm not sure that it "makes perfect sense" for them to be visible: it would surely increase the chance of name collisions outside of the package. 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 the syntax (they're outside the package). You're going to say that discriminants are outside of the type, too, but they're also visible. I can't argue with that beyond saying that that placement of discriminants is just awful; I place them in the wrong place and continually forget to include them in aggregates because they're well away from the other components. The main point is, it isn't clear either way: both choices aren't ideal. So one was chosen. And changing it surely would be incompatible, at the very least with use-visibility (if you start adding names, those names could become invisible if there are collisions) -- and it is insufficiently broken to take on that incompatibility. Randy.