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,8bb81cae35ee307f X-Google-Attributes: gid103376,public From: John G. Volan Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff] Date: 1996/02/22 Message-ID: <4gglnj$9r8@dayuc.dayton.saic.com>#1/1 X-Deja-AN: 140697795 distribution: world references: <31273ED6.B9B@flash.net> content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Science Applications International Corp. (SAIC) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-02-22T00:00:00+00:00 List-Id: In article <4gfmli$n0l@dayuc.dayton.saic.com> John G. Volan, John_Volan@ccmail.dayton.saic.com writes: >Also, if the public and private parts of a package spec could be managed >as separate operating-system files, then this would simplify some >aspects of the configuration management of packages. For instance, an >abstraction might need different implementations when ported to >different platforms. The public part of the package spec for this >abstraction would be identical for all platforms, but the package body >and the private part of the spec would need to be different on each >platform. It would be nice if we could leave the file that contained >the public part untouched, and just swap in new files for the private >part and the body when porting. It should be pointed out that the folks at ACT are planning to have GNAT provide something close to this capability, without changing the language. They're going to exploit the fact that the equation 1 Ada compilation unit = 1 operating system file is _NOT_ explicitly required by the language. GNAT will soon allow you to split an Ada package spec into a *.ads file containing everything up to and including the keyword "private" (i.e., the public part of the spec), and a *.adp file containing the rest (i.e., the private part of the spec). However, the two files together will still count as a single compilation unit. In other words, my guess is that GNAT will do little more than some text pre-processing, combining a *.ads with *.adp to generate a single file that is fed to the front end. This in itself will be useful, since it will allow the private part to be treated as a separate item for configuration management purposes. However, there are some desirable features that this will _not_ provide: (1) You won't be able to just "with" the *.ads. A "with" clause means that you're importing the whole compilation unit, including both the contents of the *.ads file and the *.adp file. (2) Unless the ACT folks intend to implement some fancy text-shuffling, a *.adp file will not be able to have its own context clause. If they go with a naive implementation that merely concatenates the *.ads with the *.adp, then the top of the *.ads file will have to contain all the "with" clauses for the package spec, including those that are only needed for the private part (and that presumably would be different for each different version of the *.adp). ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------