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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c6567772e9f3871d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.38.134 with SMTP id g6mr6500293pbk.6.1319017985443; Wed, 19 Oct 2011 02:53:05 -0700 (PDT) Path: d5ni31524pbc.0!nntp.google.com!news1.google.com!postnews.google.com!s14g2000vbj.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: organizing deep source trees with child packages Date: Wed, 19 Oct 2011 02:52:50 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <21c9e6bb-f4f7-4a00-bde7-68f2c1a42d01@q13g2000vby.googlegroups.com> <82ty7d1ewz.fsf@stephe-leake.org> <3486b228-abdd-490f-b4ef-9ee6b19f65fa@gy7g2000vbb.googlegroups.com> <7179717a-9837-476c-b564-6599a9c02acd@ff5g2000vbb.googlegroups.com> <1qk4l4n9zsdgm$.1bvxdhoq5cpx5.dlg@40tude.net> <82hb39umkd.fsf@stephe-leake.org> <82botev9j0.fsf@stephe-leake.org> <82ipnlu4to.fsf@stephe-leake.org> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 X-Trace: posting.google.com 1319017985 23275 127.0.0.1 (19 Oct 2011 09:53:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 19 Oct 2011 09:53:05 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s14g2000vbj.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-Via: ICAP/1.0 192.168.152.4 X-Google-Web-Client: true X-Google-Header-Order: HUALESRCVNK X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Red Hat/3.6-2.el5 Firefox/3.6.13,gzip(gfe) Xref: news1.google.com comp.lang.ada:18595 Content-Type: text/plain; charset=ISO-8859-1 Date: 2011-10-19T02:52:50-07:00 List-Id: Dmitry A. Kazakov wrote on comp.lang.ada: > My answer to this question was: I would not care about the convention if > the IDE showed me Ada units. Since the IDE, I am using (GPS), shows file > names, I would prefer a convention which eliminates as much as possible of > the mess introduced by the file system. I agree with this. > My guess is that the Java > convention would possibly do it better than the GNAT convention. Here you are contradicting yourself; you think that introducing more of the "mess introduced by the filesystem" will fix the problem. It won't. Placing all of your source files in one, or a few, directories will not solve the problem either, but at least it will not make it worse. > But again, if the IDE showed units in their relationships (parent-child, > generic-instance, parent-separate body) rather than files, the problem > would disappear. Correct. In my daily usage, I almost never have to browse a filesystem because my IDE (Emacs) allows me to navigate the code efficiently. >> I vote for the gnat convention, because the mapping is trivial, and >> directories are a pain. > > Yes, they are when the tools are feeble. With proper tools you would not > care. But you will always have to use a feeble tool at one point or another. Think of version control systems, backup systems, pretty- printers, find+grep, etc. which do not know, or want to know, about file naming conventions or the semantics of Ada. For these tools, keeping the filesystem layout simple is better. Granted, the tools I mentioned are not "feeble" but making them work in the presence of multiple levels of directories is an additional and unnecessary hassle. >>> Generics also adds a layer of indirection instance <-> generic-body. >>> It is just impossible to remember which is an instance of what and >>> where are instances with particular parameters. > >> Why is it necessary to _remember_ that? > > In order to find it. E.g. let you have the type Loudness and for some > reason need a logarithm of its value. You remember that you have already > instantiated Ada.Numerics.Elementary_Functions with Loudness as the > parameter somewhere, but need to remember the package name in order to > "with" it. You probably instantiated Float_IO too, where it was? The software I work on has been in existence for much longer than my presence here. I cannot possibly remember generic instantiations made ten years ago by someone else but I can easily find them using gnatfind, which is integrated in emacs. I simply do C-c C-r on the spec of the generic and I can discover all instantiations of it. In fact I have already removed some redundant instantiations after discovering them that way. Remembering all of the code is not my job; my job is to *understand* the code. I have excellent tools that do the remembering for me. > Now that was just a trivial example for which some naming schema could > easily be deployed in order to help with that. I am talking about projects > which *do* use generics, of multiple generic parameters, child generic > units etc. A file naming scheme does not help with generic instantiations because some generic instantiations are nested in other units and therefore not in a file of their own. >> What does this have to do with file names? > > Each generic instance is located in some file. Yes but there is absolutely no correspondence between the name of the file, the name of the generic instantiation, or the name of the generic itself. Especially with generic instantiations inside package bodies or even inside subprograms (e.g. passive iterators). Also, one file can contain multiple generic instantiations. Therefore, no naming convention can help discover or find generic instantiations. Only semantic navigation can. > Not really, because to me the starting point for such discussion is the > precondition that an *Ada IDE* shall show *Ada* projects, *Ada* units, > *Ada* types, not files. It seems that Emacs users disagree with this > precondition telling me how exciting it is to find|grep directories. I am an emacs user an I am telling you exactly the opposite. Emacs is great at hiding the very existence of files because its semantic browsing capabilities are outstanding. Because of this, "organizing" files in multiple directories gives zero benefit to emacs, but is a nuisance for some other tools, which we *also* have to use from time to time. Since, of course, emacs users launch these other tools from emacs, it is quite natural that, when they do occasionally need to browse a file system, they should prefer a very simple directory layout, and should not be afraid, or surprised, to see hundreds, even thousands of files in the same directory. -- Ludovic Brenta.