Big namespace cleanup

[firebird-automations]

Put all namespaces inside the Firebird namespace.

Avoid qualification of namespace when inside it or in children namespaces.

Put *_proto.h headers in namespaces.

[aafemt]

Move Why namespace inside Firebird
Move Replication namespace to Firebird::Jrd::Replication
Move namespace Ods to Firebird::Jrd::Ods

What's the purpose? It makes even less sense in company with "using namespace Firebird" everywhere.

It looks like you just wanna to kill every open PR with endless merge conflicts and build errors.

[AlexPeshkoff]

Adriano please in a few words - why is "Put all namespaces inside the Firebird namespace" needed?

[asfernandes]

Adriano please in a few words - why is "Put all namespaces inside the Firebird namespace" needed?

This has been discussed more than one time.

Did you see any other software written that uses many top level namespace? Not only in C++...

Did you think is correct to need to use :: Firebird everywhere outside common because it's well know fact that headers should not use using namespace?

Did you think it's correct to have part of the software not using namespaces and that adding namespace to it in the way they were being used would make point above even worse?

[aafemt]

The sole purpose of namepaces is preventing conflict of names. Including everything into single namespace (global namespace with using namespace as well) completely defeats this purpose, and such usage of namespace Firebird was never discussed in firebird-devel list.

I wonder: was this PR made using AI?

[asfernandes]

Alex and others core developers:

• Discussion in 2023 in thread "Namespaces": https://groups.google.com/g/firebird-devel/c/orn6f6h4Ny0/m/NBCAp5WTCAAJ
• Discussion in 2011 in thread "Namespaces": https://sourceforge.net/p/firebird/mailman/message/27345253/

In both times part of the proposals was what just I did here and that structure of namespaces had positive (certainly not negative) comments by Dmitry at least.

Or maybe the question is that 15 years was not sufficient time for the discussion to fully happen? :)

[dyemanov]

The sole purpose of namepaces is preventing conflict of names. Including everything into single namespace (global namespace with using namespace as well) completely defeats this purpose

IIRC (I haven't looked into this PR yet, so Adriano please correct me if I'm wrong), it's not about moving everything into a single namespace Firebird, but instead combining existing namespaces under a common namespace Firebird umbrella, so that namespaces become hierarchical rather than independent.

[aafemt]

it's not about moving everything into a single namespace Firebird, but instead combining existing namespaces under a common namespace Firebird umbrella, so that namespaces become hierarchical rather than independent.

Yes, but I see no difference in this case. Effectively from code POV "combining every existing things under single Firebird umbrella" in combination with using namespace Firebird everywhere is the same as removing Firebird namespace completely. It serves no purpose and solves no problems.

PS: If you are annoyed by typing Firebird:: prefix, you either move everything under Firebird umbrella or use using namespace Firebird, but not both.
Nested namespaces are not bad though even more annoying, but insisting that there can be only one root is extreme.

[asfernandes]

The sole purpose of namepaces is preventing conflict of names. Including everything into single namespace (global namespace with using namespace as well) completely defeats this purpose

IIRC (I haven't looked into this PR yet, so Adriano please correct me if I'm wrong), it's not about moving everything into a single namespace Firebird, but instead combining existing namespaces under a common namespace Firebird umbrella, so that namespaces become hierarchical rather than independent.

Of course.

C++:

• std
• std::ranges (not ::ranges)
• std::chrono (not ::chrono)
• std::filesystem (guess what?)
• ...

boost:

• boost:optional (a common class directly in boost namespace)
• boost::shared_ptr (...)
• boost::asio (a nested namespace)
• boost::math (a nested namespace)

You may start looking others libraries (in C++, C#, Java) and you will see the same pattern. It would be difficult to find something like Firebird is doing.

[aafemt]

You may start looking others libraries

Keyword is "libraries". Firebird is an application, not a library.

[asfernandes]

C#:

• System (namespace): classes: Object, String
• System.Collections.ArrayList: System.Collections is nested namespace, ArrayList is class
• System.IO: nested namespace

This is correct and common schema used to avoid extra qualification of names inside the same software package.

I can't agree with any argument against this, sorry.

What is discussable is volume of changes. For that, I only re-indented header files part with prototypes that already had the removing of ::Firebird in almost any line. I didn't re-indented implementations.

About forks and old branches, well, Firebird must evolve. Shared metadata cache had a lot of changes too, so should it be prohibited to be done? Schemas the same.

[aafemt]

Metadata cache was well localized and caused almost no conflicts. Schemas was pain in ass but really affected mostly just database queries. Both of them bring valuable features to Firebird that affect user experience.

This PR has no such value and is incomplete: if you are so fond of namespaces, you also had to cleanup old prefixes that served the same purpose, but you keep them. This end up in stupid Firebird::Alice::ALICE_main().

PS: Years ago I made the same mistake, submitting a big patch just to minimize forward declarations. That time Claudio pointed me to this mistake and I'm thankful to him for this lesson.