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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!ottix-news.ottix.net!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Multiple procedures in the same adb file? Date: Sun, 11 Jan 2015 19:53:17 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <5fc3a42d-f922-4e34-ab30-59613b980fb6@googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1421024004 27753 192.74.137.71 (12 Jan 2015 00:53:24 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 12 Jan 2015 00:53:24 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:sQ6dB/y+uhNlhw2of/4HwomjVRE= Xref: news.eternal-september.org comp.lang.ada:24542 Date: 2015-01-11T19:53:17-05:00 List-Id: Niklas Holsti writes: > On 15-01-11 21:51 , Robert A Duff wrote: >> It is unwise to have procedures outside of packages > > Why "unwise"? Because sometimes you need to add new stuff (another related procedure, for example), and then there's no good place to put it. If the existing procedure is in a package, then that's where you put it. This happened to me: Existing code: function Some_Root_Package.Some_Function(...) return String; Now I happen to know that it always returns String(1..20). And returning known-length strings is more efficient, and this one is a bottleneck, so it's worth changing to something like: subtype String_20 is String(1..20); function Some_Function(...) return String_20; But that doesn't work without adding a new package, which breaks compatibility. And this was a widely-used library, so I couldn't do that. And String_20 really doesn't belong in Some_Root_Package, nor anywhere else than the package that Some_Function is (directly) in (which didn't exist!). If the original programmer had put Some_Function in a child package Some_Root_Package.Some_Package in the first place, then I wouldn't have had these problems. I admit: these concerns are only significant for widely-used libraries. If I had been working on a program instead of a library, I would have just moved Some_Function into a package, and modified all the call sites. But it's probably a good idea to get in the habit of using "library-programming" style even when doing "program-programming", if it's not too much trouble. Besides, it complicates the language quite a bit to have misc stuff allowed as compilation units (e.g. task body subunits). I would prefer that the only unit of separate compilation be the package (and maybe generic package). >... I agree it is unusual, but I find it is sometimes useful, > in particular to have subprograms which are children of packages but are > their own compilation units. In a layered architecture, such subprograms > are sort of in a layer between the higher layer that contains the > declaration of the parent package, and the lower layer that contains the > body of that package. Sure, but you can do that with another package just as well as with a procedure. > In language-lawyer terms, perhaps such subprograms are not really > "outside of packages", because child units are in some sense "inside" > their parents, but the child subprograms are not "inside" any package in > terms of source-code files. Yes, you're right. In fact, everything is logically nested within package Standard, so everything is in a package. But I meant that everything should be physically/textually nested within a package, and packages (and generic packages) should be the only separately-compiled things. And main procedures should be (textually) in packages, instead of as standalone procedures (and that part is not Ada -- just my preference for how it ought to be!). - Bob