[haiku-development] Re: BSupportKit namespace?
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 15 Dec 2016 13:20:30 +0100
Am 15.12.2016 um 03:24 schrieb kallisti5:
I think adding a new API convention is a bit premature.
[...]
This is mostly to keep things consistent. I'm pretty sure we
aren't going to start leveraging namespaces before R1.. so why would
we introduce a new standard just before release with no planning
that we may want to rework at some point?
IMO the API currently using namespaces is experimental, and might not
have been set into stone yet (unless/until we declare it stable with R1).
Namespaces are definitely useful, and with the way linkers work, even
necessary.
The BJob is actually a good example of why this is; one could argue that
a single "B" namespace (or even "H") would be enough, that we'll be able
to find meaningful different names in our API. The end result are longer
names like "BPackageJob" instead of BJob -- the difference is marginal
IMO, even though I agree that namespaces are a bit inconvenient, they
allow you to actually type less.
I prefer to keep the "B" prefix in our class names, as it allows to use
the namespaces without having to fear name clashes until you need to use
BJob and BPackageKit::BJob at the same time.
I wouldn't mind to try to keep the number of namespace levels as low as
possible, ie. only use the kit as namespace whenever possible.
Qt is actually a grown API, too, and you can only optionally compile all
classes to be in a namespace -- only the newer parts come within their
own namespace in addition to that one.
Whether we want to encode a version into the namespace depends on if we
want to be able to have applications link against two different versions
of a library at the same time.
Bye,
Axel.
Other related posts:
