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,UTF8 Received: by 10.68.21.229 with SMTP id y5mr2376964pbe.1.1318936318819; Tue, 18 Oct 2011 04:11:58 -0700 (PDT) Path: d5ni26665pbc.0!nntp.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: organizing deep source trees with child packages 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> Date: Tue, 18 Oct 2011 07:12:03 -0400 Message-ID: <82botev9j0.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) Cancel-Lock: sha1:5taaLOelHb/k2ogDm646K96Hmlk= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 9debb4e9d5efee029e66103923 Xref: news1.google.com comp.lang.ada:18555 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Date: 2011-10-18T07:12:03-04:00 List-Id: "Dmitry A. Kazakov" writes: > On Sun, 16 Oct 2011 08:51:14 -0400, Stephen Leake wrote: > >> "Dmitry A. Kazakov" writes: >> >>> On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duchêne (Hibou57) wrote: >>> >>>> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta >>>> a écrit: >>>>> Directories are *not* a solution for these problems. They do not >>>>> represent dependencies or hide any information from the compiler. >>>> This is not a matter of semantic, this is a matter of being handy for >>>> human beings. >>> >>> Actually long file names is not the problem. The problem is that GPS in its >>> tree view control used for browsing the project units ignores the packages >>> hierarchy in favor of the hierarchy of the file system. Change that in GPS >>> (or another Ada IDE) and the problem would largely disappear. >> >> I still don't understand what "problem" is being solved here. > > Long file names, which are difficult to read. I guess we'll just have to disagree about that. Are long package names easier to read? > GPS project view shows file names, e.g.: > > gtk-layered-waveform-ring_data_buffer.adb > gtk-layered-waveform-ring_data_buffer.ads > > It should rather show simple names of Ada units, e.g.: > > gtk > |-layered > | |-waveform > | | |-ring_data_buffer > | | | |-package specification > | | | |-package body I don't use GPS, but I assume it has a package browser that shows this tree. Personally, I've never felt the need for such a view. I guess you are saying "yes, long package names are hard to read, and this tree view is a solution to that". >> A file system browser allows viewing files by file name; that's a good >> solution for a class of problems. A package browser allows browsing >> packages by package name; that's a good solution for another class of >> problems. >> >> If the file and package names are the same, then you can use a file >> browser as a package browser, avoiding the work of maintaining two >> tools. >> >> When do file names and package names _need_ to be different? > > Always. Why? Simple assertions don't get us anywhere. > Actually this is what the OP wished to have: a correspondence between > fully qualified names of Ada units and paths of the files containing > these units. The current gnat convention gives that. > Parent's name <-> directory name. Child name <-> file name. That's another alternative, with the drawbacks several of us have pointed out. >> I don't see any problem with long file names; they used to be a problem >> on 80 character terminals, but we are past that now. > > For projects of many hundred files, it is a huge problem. Not for me or Ludovic (or many others, I assume). Exactly what is the problem? > Especially when you have hundreds of generic package instances popping > everywhere. Why are generics a special case? It can be difficult to come up with good names for generic packages and their instances. I solve that with a naming convention; the package name of a generic package must start with "Gen_". > Pushing files into different directories makes things only worse. How, exactly? > The point is, when browsing a project you are not interested in files, Depends on exactly why I'm "browsing". > you are looking for Ada units, Ok, I'll suppose I'm "browsing for Ada units". I'm still not clear what that means in detail. If I'm _searching_ for an Ada unit that deals with lists, I either: 1) remember the full name exactly, and navigate there by file name (which matches the package name) 2) open a directory that contains the library that probably contains the lists packages, and search for the string "list" in the file names. If the IDE provides some other way to search for "list" in package names, that would be equally useful. (Does GPS let you search for strings in its file or package browser?) But since the Emacs file browser already provides this, I see no need to spend additional resources adding that specific capability. Maybe the real solution is to use Emacs instead of GPS or Eclipse (or anything else)? Every time I compare the three, Emacs wins hands down on features that contribute to real productivity. > and it is absolutely irrelevant what is the file name of that unit. Ok. But I can take advantage of that fact if it happens to be true. In the above scenario, if the file names do not contain the full package name, I could use 'grep list *.ads', but that's less reliable, since it would find instances of "list" in the rest of the package spec, not just the package name. Building a regexp to match only package names is possible, but not trivial. What are some other use cases for "browsing"? > In fact, if the source control systems were not so retarded, we would > have no files at all, just versions of units stored in a database. Many people have said that over the years, and Rational (I think) built a system that worked that way. It was a failure, and I'm not aware of any other system that actually works that way. The reason is the flexibility, power, and reliability of the current file based system. You'll have to make _very_ solid arguments to counter that. So far I see only vague unsubstantiated assertions. -- -- Stephe