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: dsmith@clark.net (Doug Smith) Subject: Re: AQ&S Guidance on pragma Elaborate_Body Date: 1997/04/20 Message-ID: #1/1 X-Deja-AN: 236179321 References: <528878564wnr@diphi.demon.co.uk> Organization: Clark Internet Services, Inc. Newsgroups: comp.lang.ada Date: 1997-04-20T00:00:00+00:00 List-Id: In article <528878564wnr@diphi.demon.co.uk>, jpt@diphi.demon.co.uk wrote: > In the rationale to Section 8.4.3, Coupling Due to Pragmas, the second > paragraph says:- > > "When there is a clear requirement for a recursive dependency, you > should use pragma Elaborate_Body. This situation arises, for example, > when you have a recursive dependency (i.e., package A's body depends on > package B's specification and package B's body depends on package A's > specification)." > > The most obvious interpretation of this is that the pragma should appear > in both packages - which will generate an error, probably at link/bind > time. > [snip] > Phil Thornley This was added in the '95 guidelines and I think is bad advice. This is in a section of the Quidelines for reusability, and was section 8.4.2 in the '83 Guidelines which recommended against pragma Elaborate for nongenerics. The only guideline which survived was "Use pragma Elaborate for generics named in a context clause." That could imply this paragraph was talking only of generics; however, generics cannot be mutually dependent (although instantiations can be mutually dependent in an indirect fashion). Doug p.s. I see a new section 8.4.1 which reverts to the "Consider using..." phrases I tried to remove when editing the last '83 version. Rats!