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 X-Received: by 2002:a24:7b0a:: with SMTP id q10-v6mr725001itc.26.1538058286833; Thu, 27 Sep 2018 07:24:46 -0700 (PDT) X-Received: by 2002:aca:7552:: with SMTP id q79-v6mr206439oic.1.1538058286684; Thu, 27 Sep 2018 07:24:46 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.166.216.MISMATCH!x98-v6no63699ita.0!news-out.google.com!z5-v6ni74ite.0!nntp.google.com!x98-v6no63696ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 27 Sep 2018 07:24:46 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=73.205.150.94; posting-account=Ru7E4QoAAAC_HiQ2D8LjZ7rh1mbTNcVn NNTP-Posting-Host: 73.205.150.94 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0956f152-7902-47cb-98e2-c6e5ba68b6b5@googlegroups.com> Subject: Code organization From: NiGHTS Injection-Date: Thu, 27 Sep 2018 14:24:46 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54437 Date: 2018-09-27T07:24:46-07:00 List-Id: When I programmed in C, code organization was very easy. If my code file be= came too long and complex, I'd simply create new files and separate out cod= e organized in some way. Then I would #include the C files into my main. In Ada, I've attempted to build packages so that more code can be distribut= ed into organized categories, but that only gets me so far. In one instance, I have a package that handles an xhtml object, but it has = tons of interface functions and procedures to the object the package encaps= ulates. In this case I am frustrated by the ever-growing size of this sourc= e code. The procedures themselves may be grouped into categories, so it wou= ld have been nice to move some of these procedure bodies to other files. In another instance, I have two nested tasks, and the inner task has a numb= er of local functions and objects it uses. With all this spec stuff living = inside the declarative areas deep in the body of my code, I would rather or= ganize them in another file, but I don't want to change my code to work wit= h task access pointers (I've tried this and there were problems, so I've ha= d to keep the code there). In this case, or in any case where there is a de= clarative region with private scope specs, I wonder if there is any way to = move code out of the body and into another file. Essentially the biggest hindrance is the rules of visibility. A procedure o= r task created inside the body of another one has full visibility of the va= riables within its scope. If it were possible to move the code somewhere el= se, I feel like Ada would complain that it can't see those local variables.= And if we go the route of outside procedures being passed tons of "in out"= to these local variables, then we'd have to also expose their types which = may also have been created within a local scope. Many times we need access = to a local procedure, so then I'd have to add an anonymous access procedure= as a parameter just so it can work with it. At this point, what would have= been a simple little utility procedure call has become a monster of parame= ters that makes the implementation very difficult to read. I don't think there is anything I can really do other than find creative wa= ys to create more packages, but doing so many times means writing more code= to manage the extra packages, memory access, and visibility contexts. Any thoughts on this?