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:a24:ddce:: with SMTP id t197-v6mr6889654itf.6.1541438446367; Mon, 05 Nov 2018 09:20:46 -0800 (PST) X-Received: by 2002:a9d:fed:: with SMTP id m42mr419209otd.6.1541438446085; Mon, 05 Nov 2018 09:20:46 -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-v6no392602ite.0!news-out.google.com!n199-v6ni543itn.0!nntp.google.com!g188-v6no395061itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 5 Nov 2018 09:20:45 -0800 (PST) In-Reply-To: <98c7d0b5-2262-4246-bb4f-6dde1d59ff6b@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=208.114.128.105; posting-account=MRPdDAoAAADUJmZVjnYaoafXFMadSeY1 NNTP-Posting-Host: 208.114.128.105 References: <5af3c4a0-5856-47ec-bb05-0ae9f9bb24ff@googlegroups.com> <98c7d0b5-2262-4246-bb4f-6dde1d59ff6b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <611c4691-f691-450c-845f-9d03a2d4fd77@googlegroups.com> Subject: Re: Trivia: Ada packages are great! From: Olivier Henley Injection-Date: Mon, 05 Nov 2018 17:20:46 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54769 Date: 2018-11-05T09:20:45-08:00 List-Id: > Except when the original and target package names need to differ or are i= n a different package hierarchies.=20 I do not get this one? > Or perhaps somebody decides that what was originally sitting alone in a c= osy Utils package needs to be integrated within an already existing (and cr= owded) Our_Very_Complex_System.Utilities.Helpers. I disagree. 1. 99% of the time, people have their own 'utils, math etc' that does exact= ly what 25 other 'projects' does and NOBODY tries or even care to merge int= o a cohesive 'utils, math etc' package.=20 2. Merging code under the same umbrella is tedious, cut, copy, paste, renam= e etc but not hard. At least it removes complexity. Keeping alive duplicat= e type naming through 'disfigure' mechanism is another story. C++ big proje= cts are full of that. > Which, considering your assertion that the target is a MUCH bigger codeba= se, would be the case almost certainly. hundreds++ of visual studio projects. > Unfortunately, no. Complex projects are complex in whatever language and = code migration and integration are hard, for everybody. The problem I had would have been easily solved in Ada. The guy would have = named his code cathedral something like: eg. ConsultingCompanyCathedral.AnU= sualTypeName and merging would have not clashed at all because since the be= ginning of times the official Matrix type would have been forcefully scoped= eg. OurFlagshipProduct.Whatever.AnUsualTypeName > Interestingly, the feature that allows C++ namespaces to exists in multip= le files, makes the code migrations easier, because new definitions can be = added to existing namespaces without any need to modify existing files. Thi= s also means that new features can be written and tested in an isolated env= ironment, with target namespaces already in mind, and then new files just a= dded to the project. In comparison (and in this context), Ada couples logic= and physical designs, which is not always wanted. You can argue/present it the way you want but stitching official, cast in s= tone, legacy types (not namespaced) that are visible everywhere + new publi= c types declared inside classes + forward declare + anonymous namespace + p= artial implementation in .h files is a ****** nightmare. It is so convolute= d that you end up fighting Visual Studio for the whole thing to compile und= er thousands of misleading errors so ... I fail to see where, practically, = there is such thing as "C++ (...) makes the code migrations easier". This I love: presenting the C++ capabilities conceptually 'sandboxed', forg= etting that it exposes SO much potentially 'skewed capabilities' that facin= g the 'working, proper, clean context' for those capabilities to actually b= ehave like expected is virtually impossible. What you describe works fine with people sharing the same architectural con= ventions, with super good doc, with very tight knowledge of C++ exceptions = to exceptions, with small code base, with same epoch code base. Once you to= ss some of those aspects out, to name a few, the whole thing becomes a madh= ouse.=20 Look. In real life, companies have to hire hundreds of C++ guys to push leg= acy or new stuff forward. We are either morons or there is an obvious probl= em with the tech, yours to choose.=20