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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a02:57c4:: with SMTP id b65-v6mr18061021jad.15.1541414362699; Mon, 05 Nov 2018 02:39:22 -0800 (PST) X-Received: by 2002:a9d:ea8:: with SMTP id 37mr462702otj.1.1541414362384; Mon, 05 Nov 2018 02:39:22 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!z5-v6no89590ite.0!news-out.google.com!t123-v6ni7itb.0!nntp.google.com!g188-v6no96278itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 5 Nov 2018 02:39:22 -0800 (PST) In-Reply-To: <5af3c4a0-5856-47ec-bb05-0ae9f9bb24ff@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.9.244.28; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 194.9.244.28 References: <5af3c4a0-5856-47ec-bb05-0ae9f9bb24ff@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <98c7d0b5-2262-4246-bb4f-6dde1d59ff6b@googlegroups.com> Subject: Re: Trivia: Ada packages are great! From: Maciej Sobczak Injection-Date: Mon, 05 Nov 2018 10:39:22 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54765 Date: 2018-11-05T02:39:22-08:00 List-Id: > I just want to recall that in Ada being forced to choose a package name f= or our units is a frustration/time/clarity saver. Integrating would have ta= ken nothing.=20 Except when the original and target package names need to differ or are in = a different package hierarchies. Or perhaps somebody decides that what was = originally sitting alone in a cosy Utils package needs to be integrated wit= hin an already existing (and crowded) Our_Very_Complex_System.Utilities.Hel= pers. Which, considering your assertion that the target is a MUCH bigger codebase= , would be the case almost certainly. > Anyone arguing that enforcing explicit separation of code units is a wast= e of time or tutoring for bad programmers is plain wrong.=20 Yes. > This is one of the many reasons why Ada, in the long run, kills it.=20 Unfortunately, no. Complex projects are complex in whatever language and co= de migration and integration are hard, for everybody. Interestingly, the feature that allows C++ namespaces to exists in multiple= files, makes the code migrations easier, because new definitions can be ad= ded to existing namespaces without any need to modify existing files. This = also means that new features can be written and tested in an isolated envir= onment, with target namespaces already in mind, and then new files just add= ed to the project. In comparison (and in this context), Ada couples logic a= nd physical designs, which is not always wanted. --=20 Maciej Sobczak * http://www.inspirel.com