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.

You can argue/present it the way you want but stitching official, cast in stone, legacy types (not namespaced) that are visible everywhere + new public types declared inside classes + forward declare + anonymous namespace + partial implementation in .h files is a ****** nightmare. It is so convoluted that you end up fighting Visual Studio for the whole thing to compile under 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', forgetting that it exposes SO much potentially 'skewed capabilities' that facing the 'working, proper, clean context' for those capabilities to actually behave like expected is virtually impossible.

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 a madhouse. 

Look. In real life, companies have to hire hundreds of C++ guys to push legacy or new stuff forward. We are either morons or there is an obvious problem with the tech, yours to choose.