Beyond 2.8 - namespaces

[Geert Janssens]

Op maandag 25 december 2017 00:34:39 CET schreef John Ralls:
> > On Dec 24, 2017, at 8:34 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:
> > We can debate whether our internal code can/should have "namespace gnc;"
> > in
> > headers only or in source files as well. For libgnucash I'd go for the
> > latter. It  The context should be clear there. In the gnucash gui related
> > code (the parts that are C++ obviously), I would as well, though I have a
> > less strong opinion there.
> 
> I don’t think you meant what you said there because I know that you know
> that once you declare something in a namespace you have to either refer to
> it with the namespace qualifier everywhere or alias it in to the scope’s
> namespace with ‘using’.
> 
Yes, what I wrote is pretty confusing and in hindsight convoluted as well. I 
was mostly considering whether we'd use

namespace gnc
{
...
}

in both header and source files or whether we'd only use that construct in the 
header file and explicitly prefix the definitions and calls with gnc:: in the 
source files (to maintain namespace protection there). 

I'm not even sure the latter would be allowed so I think only the first would 
make sense in libgnucash, applying 
namespace gnc
{
...
}
in both header and source files.

> Perhaps you mean that you’re not sure if compilation-unit-local functions
> and variables (those typically declared static in C) should also be in the
> gnc namespace. I don’t think so. There’s a special compilation-unit-local
> namespace called the anonymous namespace for that.
> 
That's clear.

> Should the gnc namespace be applied to classes throughout the application or
> just to libgnucash classes? I’m inclined to think the latter. The
> application itself doesn’t really benefit from a namespace though some of
> its modules might.

My limited namepaces experience shines through here... I re-read a bit about 
it and agree. We should only apply the gnc namespace in libgnucash and not to 
classes in the rest of the application. I was really thinking of using the 
"using namespace gnc;" directive in the rest of the application. I consider it 
reasonable for the application that's really built around the library to do 
without the namespace protection for that library.

Using namespaces in the libgnucash allows other consumers the freedom to 
choose whether or not they want the namespace protection, similar to how we 
can choose this for std:: or boost:: namespaces. Personally I would not drop 
the namespace protection for libraries not maintained in the same project 
though. If the namespaces get too long, we can go with carefully chosen 
aliases (something to find a consistent rule for as well).

> Your division of the code into libgnucash and gnucash is
> a first good cut but I’m sure we agree that it’s going to need refining in
> the next development cycle. Working out namespace divisions can help with
> that refinement because the namespaces will make logical groupings more
> apparent.

Agreed indeed. For example in my work on the importers I have introduced a 
strict separation of import functionality and gui. So the non-gui parts of the 
importer should move to libgnucash eventually as I want them to bepart of the 
api. That way they can be used by other applications (mobile apps, web 
app,...) and would be available to the bindings as well. I can't do this yet 
because this separation is only done for the code I touched (the csv 
importer). That code is still embedded in a larger import framework which  
does not (yet) have this separation.

My inclination to use namespaces for the importer should have been a good hint 
it really belongs in libgnucash, but I didn't realize than when I wrote the 
proposal :)

In all I'm happy you agree on using namespaces in general. That's enough for 
now. We can indeed work out a more detailed hierarchy when we're done with 
2.8.

Geert