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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.cs.hut.fi!goblin2!goblin.stu.neva.ru!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: body stub not allowed in inner scope Date: Fri, 2 Mar 2018 16:13:40 -0600 Organization: JSA Research & Innovation Message-ID: References: <55cd79f5-4b37-4b08-b292-073ed2f37021@googlegroups.com> <15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com> Injection-Date: Fri, 2 Mar 2018 22:13:41 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="9701"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:50800 Date: 2018-03-02T16:13:40-06:00 List-Id: "J-P. Rosen" wrote in message news:p7atjs$1qme$1@gioia.aioe.org... > Le 01/03/2018 à 23:38, Randy Brukardt a écrit : >> Yes, but why put them in a separate file in the first place? The only >> reason >> I know not to do that is that editors (and compilers) used to have size >> limits. It's usually easier to have one big file because it makes fewer >> places to look for things. (The subunits in Janus/Ada are annoying >> because >> one opens the body to find something only to find it isn't there and a >> different file has to be opened. Often, I don't know exactly what I'm >> looking for and have to bounce back and forth several times.) >> > I think your opinion is closely linked to the fact that you don't use > (AFAIK) modern editors. With GPS or Emacs, you click on an entity and > "goto declaration" to retrieve it. OTOH, long scrolls are annoying, so > there is a clear benefit in having your stuff split on several, not too > big files. Lots of windows are annoying, too; it is hard to get the right one on top. Even if you use a "goto declaration", now you have the wrong window on top and getting back is a pain. (My old editor tiles windows and thus avoids this problem.) I'm generally not looking for "a declaration", I'm looking for code that implements something, typically written 30 years ago, sometimes by someone else, whose name I don't know (perhaps I have an idea, but it's often wrong), and I don't know how it works. No editor is going to help significantly with that. I don't use "modern editors" not because I'm some sort of Luddite, but rather because I want to "eat my own dog food" and thus not depend on something that we don't have for them. Regardless, the majority of "goto declaration" commands are intensely frustating, because they don't handle most of the subtle visibility issues of Ada (or they require correct compilable code to do so), they don't have a sane way to deal with inheritance and instances (where you need to see both the original routine and the actuals/type declaration in order to know what's going on), and just don't match what the compiler sees. To do this right, you need a special Ada compiler that can deal with partial sources and the like - which would cost as much to develop as an actual Ada compiler. (Indeed, Ada is spending many man-years on exactly such a project.) We couldn't afford it, so that's a feature you most likely will never see in a Janus/Ada IDE. Scrolling is annoying, yes, but that's easy to mitigate by not doing it. :-) Search for something (I usually use "procedure") in long files. Once you get the to right place, you're going to have to scroll in any case (most of the subprograms in Janus/Ada are quite long because of all of the different cases that have to be dealt with, >500 lines is not uncommon). Randy.