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,45abc3b718b20aa3 X-Google-Attributes: gid103376,public From: Dennison Subject: Re: Two ideas for the next Ada standard Date: 1996/09/05 Message-ID: <322F94E9.28C6@iag.net>#1/1 X-Deja-AN: 178793951 references: <5009h5$ir4@netline-fddi.jpl.nasa.gov> <503sbo$j45@goanna.cs.rmit.edu.au> <507akg$t9u@krusty.irvine.com> <322D0803.3E5E@iag.net> content-type: text/plain; charset=us-ascii organization: The Dennison Family mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.02 (Win95; I) Date: 1996-09-05T00:00:00+00:00 List-Id: Robert Dewar wrote: > > T.E.D. asked, replying to me: > > "> Two things we have considered adding as options to GNAT, which are not > > extensions, merely source representation issues, are to allow the > > private part to appear in a separate file, or to allow it to appear > > in the body. > > Wouldn't that make package bodies dependant on the BODIES of every package > that they "with" (even indirectly)? It seems like that could really balloon > compilation times. How would the inevitable circular dependancies be handled?" > > Well you are dependent on bodies anyway if there is any inlining or any > generic subprograms. True, but only on the body of the inlined or generic subprogram. The proposed change would make compilation units dependant on every spec and body "with"ed in every spec AND BODY (recursively). In my experience, package bodies tend to have a LOT more "with"'s than specs. Compilations that now take hours might end up taking DAYS! Then again, I guess there is a limiting factor (ie: the total # of specs and bodies in the system). This would just drasticly increase the % of compilation units in the entire project that the average compilation unit depends on. -- email - mailto:dennison@iag.net homepage - http://www.iag.net/~dennison