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.21.229 with SMTP id y5mr5246336pbe.1.1318989067811; Tue, 18 Oct 2011 18:51:07 -0700 (PDT) Path: d5ni29929pbc.0!nntp.google.com!news2.google.com!npeer01.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> <82botev9j0.fsf@stephe-leake.org> Date: Tue, 18 Oct 2011 21:51:15 -0400 Message-ID: <82ipnlu4to.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) Cancel-Lock: sha1:k1qLhDFVTxySH2wQnukubjcbrMM= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 9c0624e9e2d0be029e66117541 Xref: news2.google.com comp.lang.ada:14071 Content-Type: text/plain; charset=us-ascii Date: 2011-10-18T21:51:15-04:00 List-Id: "Dmitry A. Kazakov" writes: > On Tue, 18 Oct 2011 07:12:03 -0400, Stephen Leake wrote: > >> "Dmitry A. Kazakov" writes: >> >>> 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? > > They are not long, fully qualified names are long. > >>>> When do file names and package names _need_ to be different? >>> >>> Always. >> >> Why? Simple assertions don't get us anywhere. > > "c:\mess\foo.adb" /= "Foo" You seem to be deliberately misrepresenting the question. No one is talking about the absolute path as "the file name"; we are only talking about the part of the path that maps to the Ada package name. So far, the choices seem to be: package name Foo.Bar.Baz gnat convention foo-bar-baz.ads "java" foo/bar/baz.ads gnatkr f-barbaz.ads something else fobaba.ads Which of these is best, and why? I vote for the gnat convention, because the mapping is trivial, and directories are a pain. >>> Especially when you have hundreds of generic package instances popping >>> everywhere. >> >> Why are generics a special case? > > Because they add a multiplication factor in the number of packages for each > varying generic formal parameter. If the same packages were implemented without generics, there would be the same number of files (minus the actual generic files). I don't see that as a significant issue in this discussion. > 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? What does this have to do with file names? Unless you are attempting to encode all of that information in the file name and/or the package name, you are just confusing things by bringing this into the discussion. >>> Pushing files into different directories makes things only worse. >> >> How, exactly? > > You must also remember the directories. If you need to find a unit you > first have to go to its directory and then start searching. Yes, I agree; that's why I have only a few directories, each with hundreds of files. > >>> The point is, when browsing a project you are not interested in files, >> >> Depends on exactly why I'm "browsing". > > While programming/reviewing/testing/debugging an Ada program. Still not specific enough. What demands do the various activities place on the browser? I do that all day, and never feel the need for anything more than the Emacs file browser, together with Emacs Ada mode navigation, gives me. Which means I'm either "looking for a file" in the file browser, or "finding the spec/body for this identifier". >>> 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?) > > It does, but it is far slower than browsing, because it involves typing, > browsing the results of the search, and is contaminated by the results > coming from with/use. So the Emacs file browser is more efficient for this task. I find it more efficient for all tasks :). >> 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. > > You know, Emacs users and us, the others, represent different species. I'm > certain that a scientific study would show that these don't even > interbreed. Each Emacs user must have been abducted by aliens in flying > saucers... (:-)) Yes, it often seems that way. That doesn't mean we can't have a technical discussion, to understand what the issues are, and how to improve both Emacs and GPS to make them both better. >>> 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"? > > Browsing is more like looking at the list of packages to see how they are > related etc. File names give very little information on that. I don't think I learned anything from this message. -- -- Stephe