Re: Trivia: Ada packages are great!

[Olivier Henley <olivier.henley@gmail.com>]

> Except when the original and target package names need to differ or are in a different package hierarchies. 

I do not get this one? 

> Or perhaps somebody decides that what was originally sitting alone in a cosy Utils package needs to be integrated within an already existing (and crowded) Our_Very_Complex_System.Utilities.Helpers. 

I disagree. 

1. 99% of the time, people have their own 'utils, math etc' that does exactly what 25 other 'projects' does and NOBODY tries or even care to merge into a cohesive 'utils, math etc' package. 

2. Merging code under the same umbrella is tedious, cut, copy, paste, rename  etc but not hard. At least it removes complexity. Keeping alive duplicate type naming through 'disfigure' mechanism is another story. C++ big projects are full of that. 

> Which, considering your assertion that the target is a MUCH bigger codebase, 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.AnUsualTypeName and merging would have not clashed at all because since the beginning 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 multiple files, makes the code migrations easier, because new definitions can be added to existing namespaces without any need to modify existing files. This also means that new features can be written and tested in an isolated environment, with target namespaces already in mind, and then new files just added 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 types (not namespaced) that are visible everywhere + some of those new types declared inside classes + forward declare + heavy use of anonymous namespace + 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 interacting 'skewed capabilities' that facing the 'working, proper, clean context' for those capabilities to actually behave like expected is rarely, very rarely, the case. 

What you describe works fine with people sharing the same architectural conventions, with super good doc, with very tight knowledge of C++ exceptions to exceptions, with small code base, with same epoch code base. Once you toss some of those aspects out, to name a few, the whole thing becomes ... IMO, a madhouse.

In real life, companies have to hire hundreds of C++ guys to push legacy and/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 code base so I cannot pinpoint typical cases gone wrong, but the fact that things are "more square" and because I build and inspect relatively big open-source Ada project from time to time it appears to me that Ada is light years more truthful to help solving a practical goal at hand.