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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,775bc4aee028e5e9 X-Google-Attributes: gid103376,public From: matthew_heaney@acm.org (Matthew Heaney) Subject: Re: Q's: nested packages / visibilty Date: 1998/11/19 Message-ID: #1/1 X-Deja-AN: 413425509 Content-transfer-encoding: 8bit References: <9v6hGdgMLuwN-pn2-VFf4e0fMp6MD@dt182n2f.tampabay.rr.com> Content-Type: text/plain; charset=ISO-8859-1 Mime-Version: 1.0 NNTP-Posting-Date: Wed, 18 Nov 1998 23:23:30 PDT Newsgroups: comp.lang.ada Date: 1998-11-19T00:00:00+00:00 List-Id: In article <9v6hGdgMLuwN-pn2-VFf4e0fMp6MD@dt182n2f.tampabay.rr.com>, cpallen@nospam.com (Craig Allen) wrote: >I have questions concerning nested packages. > >1st question: > >I want to take a package and divide it up into several pieces. As I >understand it, there are 2 ways to do this. > > 1 way places the specifacation (declaration?) for the nested >package inside the specification for the parent package. This causes >the contents of the sub-package to be available to any unit >referencing the parent package. Correct. > The other places the spec for the nested package inside the >declarative part of the body of the parent package. In this way, only >the parent is allowed to use the procedures in the sub-package. Correct. >What I'm wondering is this: Is there a way to have a sub-package that >has some of its procedures visible only to the parent package, and >others that are visible to external units? (Where does the spec go?) Not really. In general, I would avoid nesting packages anyway. Just declare the things you'd declare in the nested package right in the (spec of the) enclosing package. It's a pain for clients to have to refer to items in a nested package, and it tends to create large packages. >I thought about using 'private' to do this, but that seems to apply to >data types. Could it also apply to procedures? You can declare procedures in the private part of the spec, but it doesn't buy you very much. Just declare them in the package body. >2nd related question: > >When I make a sub-package that will be used only by the parent >package, The sub package body & spec both appear in the declarative >part of the parent package. Now I see I can use 'separate' to move >the body to another (compilation unit) - this cleans the code up quite >a bit and is exactly what I'm looking for. Yes. >Can I not also do >something about the specification for this sub-package? Right now it >is still sitting in the parent package. I would like to move it to >it's own separate file as well, and somehow just include it in the >parent, but I don't think you can put a 'with' there, and if I try to >put the with for this file at the top of the parent package, it >doesn't work. Isn't there a way for me to clean this up further by >moving this (possibly lengthy) package specification elsewhere? Why not just make it its own library level unit? In general, you want to submit as little program text to the compiler as possible. If you have a "possibly lengthy" package that's nested, then move it out of there, so it's not nested anymore. About the only reason to create a nested package is to give the nested package visibility to the private part of the enclosing package. The problem is that it creates humongous packages, which creates compilation headaches. In Ada 83, if you want to share some private information, move that information out into an (unencapsulated) different package, that is with'd by the two existing packages. ie, instead of package P is package Q is ... end Q; ... private end P; do this: package P_Private is end P_Private; with P_Private; package P is ... private end P; with P_Private; package Q is ... private end Q; Of course, P_Private is unencapsulated, but this is harmless, as long as everyone agrees not to with P_Private. That package is for the exclusive use by P and Q. No, there is no way to enforce this in Ada83, but that's why Ada95 was invented.