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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!att!cbnewsl!arny From: arny@cbnewsl.att.com (arny.b.engelson) Newsgroups: comp.lang.ada Subject: Re: File name conventions for Ada units Keywords: Ada, files, conventions, standards Message-ID: <1990Oct2.171010.28845@cbnewsl.att.com> Date: 2 Oct 90 17:10:10 GMT References: <589@censun1.UUCP> <2190@sparko.gwu.edu> Organization: AT&T Bell Laboratories List-Id: In article <2190@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes: > In article <589@censun1.UUCP> cew@censun1.UUCP (SSUID Craig E Warsaw) writes: > > [the DEC convention of pkg_.ada for spec, pkg.ada for body, pkg__unit for subs] [the more common convention of pkg_s.ada for spec and pkg_b.ada for body] > [VADS only accept ".a", and Irvine only accepts ".ada", how annoying] > [extrapolating from Meridian's convention... > I would go further and use .ads for a spec, .adb for a body, .ada for a > main, and maybe .sub or whatever for a subunit. Why there are compilers, in > this day and age, that limit file types to some predetermined value, is > absolutely beyond me. At most there should be a default which can always > be overridden. > > Are others frustrated with these seemingly unjustifiable compiler limits? > Can some compiler folks out there justify the limitations? Maybe I'm > missing something here. I agree that restrictions like Verdix and Irvine put on file types is unacceptable. But making Ada file types a standard, or even a uniform convention, is not (IMHO) a good idea. There are simply too many different operating system file name formats still around. Some limit file types to 3 characters, some (I think) still limit it to 1, others have no limit. Overall file name length can be limited to 8, 14, or any number of chars. It's easy to see where any one format could result in conflicts with other tools in the environment that create files with the same extensions. (The ".a" is an obvious example). I don't want to lose my source code because some CASE tool decides to create a file with the same name, especially in UNIX where I don't have old versions. Personally, I like the following: spec body main subunit x_s.ada x_b.ada x.ada x_subname_b.ada Where "x" is the name of the compilation unit, which always ends in "_pkg", "_task", "_proc", or "_func". Of course, this works best when file name length isn't limited (or you don't use subunits :-) ). -- Arny Engelson att!wayback!arny