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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/30 Message-ID: #1/1 X-Deja-AN: 238835296 Distribution: world References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> <5jfukp$lda@top.mitre.org> <33660F4B.1B45@sprintmail.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-04-30T00:00:00+00:00 List-Id: In article mheaney@ni.net (Matthew Heaney) writes: > I'm certainly not advocating large packages. It's just that very often, > there are a small number of types (read: 2) that need to know about each > other's representation, or that one needs the know the represenation of the > other (the iterator above). > > This is just the concept of a friend in C++: to implement that in Ada, you > put the types together in the same package. No big deal. I disagree. "Friendship" typically has more to do with types that need *implementation* information about one another in order to be efficient. And it is not bi directional - no mutual dependence. This is almost always something that happens after the creation of one of the types - a new type is defined which utilizes another as a component [note: not as a parent class - that is handled by inheritance and protection]. In Ada this sort of thing is handled by child packages which can a) be defined way after the fact and b) still have direct information about the implementation of the used type. The notion of mutually dependent types is a very different thing altogether. In C++ this is handled (basically) via forward declarations. And there is no direct analog (capability) for this in Ada except incomplete types. But these require everything to be in the same _immediate_ scope. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com