Namespaces

[Adriano dos Santos Fernandes]

Hi!

Our namespaces are very problematic, particularly the sub-components
namespaces (Jrd) being defined at top level and requiring usage of
Firebird:: in every header.

With C++17 nested namespaces, we have a better tool to improve this,
defining nested namespaces in more compact way than up to C+14:

namespace Firebird::Jrd {}

So if "Jrd" is inside Firebird, every usage of common classes in Jrd
headers will not require Firebird::

This would require a lot of file search and replacements, as well manual
edits, so I'd like to discuss if we also want to maintain the names and
case style too.

For me the namespaces with initial capital letter is a bit weird. My
personal opinion is to start with lower case. But at same time we
already have public Firebird namespace, with may be alias.

Another topic is the names. Should we continue using "Jrd" (with
currently is used for jrd and dsql directories) or go to something like
"engine"?

The names things are just my personal taste, so would be good to know if
others are ok with the current standard or would like some changes which
may better be done at same time with the initial point.


Adriano

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 29.06.2023 13:15:
> For me the namespaces with initial capital letter is a bit weird. My
> personal opinion is to start with lower case. But at same time we
> already have public Firebird namespace, with may be alias.

I think that rules for namespace names should be the same as for classes:
CamelCase with initial capital letter. They both are "containers" for other
symbols after all and have the same syntax.

--
WBR, SD.

[Mark Rotteveel]

As far as I'm aware, for namespace usually all lowercase is used, in
contrast with classes and other types.

For example, see the Google C++ styleguide at
https://google.github.io/styleguide/cppguide.html#Namespace_Names

Mark
--
Mark Rotteveel

[Alex Peshkoff]

I do not have strong opinion how to type namespaces better - but I
dislike an idea of changing sources in this direction. This will cause
nothing except additional merge errors when porting changes across versions.

[Adriano dos Santos Fernandes]

You mean renaming namespaces or also fix the Firebird:: prefix spread in
all headers?


Adriano

[Dmitry Yemanov]

I don't have any preference re. lowercase vs CamelCase for namespaces.
Also, personally, I'd prefer (and already suggested that in the past) to
have the "engine" naming rather than "jrd". But both points give us very
little practical benefit while complicating the merges (and not only
backporting patches into release branches, but also syncing the code
between forks), so I'm not going to push my personal preferences.

As for nested namespaces, I see some real benefits in that. But this is
also likely to affect merges, and so far I'm somewhat sceptical whether
the change would worth it. This is discussable though.


Dmitry

[Adriano dos Santos Fernandes]

On 30/06/2023 05:27, Dmitry Yemanov wrote:
>
> I don't have any preference re. lowercase vs CamelCase for namespaces.
> Also, personally, I'd prefer (and already suggested that in the past) to
> have the "engine" naming rather than "jrd". But both points give us very
> little practical benefit while complicating the merges (and not only
> backporting patches into release branches, but also syncing the code
> between forks), so I'm not going to push my personal preferences.
>
> As for nested namespaces, I see some real benefits in that. But this is
> also likely to affect merges, and so far I'm somewhat sceptical whether
> the change would worth it. This is discussable though.
>

It would be very unfortunate if we can't or we should always think (and
not act, because of precedents) if we can't change the code because it
will be many edits and will complicate life of forks and merges.

If we had no window for that, we would still be using C.

In topic "Split ExprNodes, BoolNodes and StmtNodes" about rename/move
many files, you all agree that while it's annoying it's something we can do.

If things like
"Firebird::GenericMap<Firebird::Pair<Firebird::Left<Firebird::PathName,
WorkerAttachment*> > >" is considered normal and cannot be improved,
then it's not adopting new C++ versions that is going to improve our
code. On the contrary, we'll need to redo modern to outdated code in
backports, so if we think this way, we're stagnated forever.


Adriano