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.

[AlexPeshkoff]

On 3/7/26 15:10, Adriano dos Santos Fernandes wrote: *asfernandes* left a comment (FirebirdSQL/firebird#8930) <#8930 (comment)> Alex and others core developers: * Discussion in 2023 in thread "Namespaces": https://groups.google.com/g/firebird-devel/c/orn6f6h4Ny0/m/NBCAp5WTCAAJ

If we talk about backlinks to old discussions - well, that time I've gave explicit dislike to this suggestion: https://groups.google.com/g/firebird-devel/c/orn6f6h4Ny0/m/b1IMhqeYCAAJ Thinking twice - I still dislike a suggestion to change from CamelCase when typing namespace names. I do not understand how is 'engine' better than 'Jrd'. But I can agree that moving all classes under Firebird umbrella is good idea, i.e. use Firebird::Jrd instead plain Jrd is useful change. What I dislike is a moment in release cycle chosen for it - please leave it till next major release.

[aafemt]

But I can agree that moving all classes under Firebird umbrella is good idea, i.e. use Firebird::Jrd instead plain Jrd is useful change.

Could you clarify, please, what exactly is useful in typing Firebird::Jrd instead of plain Jrd?

As I said, Firebird is not a library (except C++ API where namespace Firebird has a good use), so there is no need to care about names' conflict with other libraries.

[asfernandes]

@AlexPeshkoff
If you read a few lines of the changes, you will see I maintained the bad names and case format.
I waited to do this after your metadata changes.
I will not redo it, sorry. 15 years of vacuum in discussions. Discussions always ended with messages from me and others didn't continuing.
If not did now, I will close PR, delete branch and we maintain that shit way to code forever.

[aafemt]

Discussions always ended with messages from me

So do mines. It is just a sign that you are ignored.

[dyemanov]

I would not object to merge it into v6, but only after all other PRs that are waiting in the pipeline. Ideally, after Alpha 1 is released.

[AlexPeshkoff]

Adriano, when I did look at the code in this branch (not very attentively, but enough to understand what was done). I've mentioned CamelCase and existing namespace names in order to emphasize that this requirements were satisfied in your PR, sorry if it was not explicit enough.

And finally I agree with Dmitry - PR is OK to be merged after Alpha1 release, moreover we will almost for sure need Alpha2.