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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:e50c:: with SMTP id y12-v6mr2517789ioc.18.1541440567598; Mon, 05 Nov 2018 09:56:07 -0800 (PST) X-Received: by 2002:a9d:43:: with SMTP id 61mr475461ota.3.1541440567286; Mon, 05 Nov 2018 09:56:07 -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-v6no419577ite.0!news-out.google.com!n199-v6ni543itn.0!nntp.google.com!g188-v6no422382itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 5 Nov 2018 09:56:06 -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: <9d824998-00fb-4c65-8b49-2183af65366a@googlegroups.com> Subject: Re: Trivia: Ada packages are great! From: Olivier Henley Injection-Date: Mon, 05 Nov 2018 17:56:07 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54770 Date: 2018-11-05T09:56:06-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?=20 > 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.=20 I disagree.=20 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.=20 > Which, considering your assertion that the target is a MUCH bigger codeba= se, would be the case almost certainly.=20 hundreds++ of visual studio projects.=20 > Unfortunately, no. Complex projects are complex in whatever language and = code migration and integration are hard, for everybody.=20 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=20 > 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. Merging new clashing type names AND file names with cast in stone, legacy t= ypes (not namespaced) that are visible everywhere + some of those new types= declared inside classes + forward declare + heavy use of anonymous namespa= ce + partial implementation in .h files happened to be a nightmare. Sidenote: This I love. You are presenting the C++ capabilities conceptually= 'sandboxed', eluding the fact that it exposes SO much potentially interact= ing 'skewed capabilities' that facing the 'working, proper, clean context' = for those capabilities to actually behave like expected is rarely, very rar= ely, the case.=20 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 ... IM= O, a madhouse. In real life, companies have to hire hundreds of C++ guys to push legacy an= d/or new stuff forward. I think we are either morons or there is an obvious= problem with the tech, yours to choose. I never worked with a huge Ada cod= e base so I cannot pinpoint typical cases gone wrong, but the fact that thi= ngs are "more square" and because I build and inspect relatively big open-s= ource Ada project from time to time it appears to me that Ada is light year= s more truthful to help solving a practical goal at hand.