[haiku-development] Re: BSupportKit namespace?
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 16 Dec 2016 07:29:49 +0100
On Thu, Dec 15, 2016 at 03:26:36PM -0600, kallisti5 wrote:
On 2016-12-15 14:41, Ingo Weinhold wrote:
On 12/15/2016 02:27 AM, Jessica Hamilton wrote:
If this is the way forward, wouldn't it also be better to revise how
the naming scheme should work for new kits?
The current approach is extremely wordy, and with our 80 character
line limits, not exactly ideal.
Something along the lines of a global namespace, kits without kit in
their name, and maybe dropping the B prefix, such as:
be::support::Job. Maybe there is a case to keep the B prefix still, if
we import namespaces to cut down on typing.
+1, though I'd go with haiku::*. With C++11 a nostalgic API user (or
source compatibility wrapper) might even use:
#include <haiku/support/Window.h>
using BWindow = haiku::interface::Window;
+1, this design is fine and makes a bit more sense.
Are we going to omit the BPrivate namespace with this change
as well? I've been having a hell of a time with it in the package
kit. (ambiguous namespace issues with BPrivate collisions)
We need to keep some "private" or "experimental" namespace, with
everything inside it available in static libraries. This allows
breaking the ABI of these parts without preventing existing apps using
them to run. When the API/ABI is finalized, we move these classes out of
BPrivate and to a shared library.
Your problem is that the package kit uses BPackageKit::BPrivate, which
conflicts with the top-level BPrivate. There are several solutions:
- Always use the complete namespace-path when referring to these classes
(::BPrivate for the top level one, and BPackageKit::BPrivate for the
package kit one)
- As Ingo suggested, create aliases (using PackagePrivate =
BPackageKit::BPrivate) if using C++11
- Find a scheme where such conflics don't happen, but I can't think of
an obvious one (BPackagePrivate namespace? Remove the top-level
BPrivate one so everyhting is in some B*::BPrivate?)
Do we want it versioned?
r1::interface::Window r1 api
r1::support::Job
v1::support::Job "v1 api"
Yes, but I would not make these changes now. We'll start doing this for
R2.
I could change the BJob api to match whatever namespace design
so it can be experimented with in r1. (automatic documentation, etc)
We don't document BJob or use it anywhere except the
package kit.
Doesn't the Launch Daemon use it as well? IIRC that's why it has been
moved to the support kit?
Anyway, that leaves us with:
r2::haiku::interface::Window
r2::haiku::support::private::Job
using namespace r2;
(the r2 namespace is there to differenciate versions of the API, if we
want to do this using namespaces. It is "using" by default so not
visible to API users - we can remove the need for that if we use some
other way to do the versionning, gcc has "symbol versions" using
function attributes now, for example)
--
Adrien.
Other related posts:
