Op maandag 25 december 2017 00:34:39 CET schreef John Ralls:
> > On Dec 24, 2017, at 8:34 AM, Geert Janssens <geert.gnuc...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
