Re: glibmm: Creating a DBus namespace?

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 16 Feb 2011 10:54:20 +0100
Murray Cumming <murrayc murrayc com> wrote:
> On Tue, 2011-02-15 at 12:53 +0000, Chris Vine wrote:
> [snip]
> > It is glibmm which has an inconsistent usage, by separating off only
> > gio into a separate namespace (which incidentally is ::Gio, not
> > Glib::Gio), which may be the source of what you find confusing.
> > There seems no particular reason why there should not be GThread,
> > GObject and GModule namespaces in glibmm:
> 
> Would there be much in those namespaces? There isn't much point in a
> namespace that has only one class. But if there are more classes per
> those namespaces, please do put the suggestion in bugzilla so we can
> consider it later.

I take your point but a GObject namespace could have all the
Glib::Object, Glib::Parameter*, GlibSignalProxy* and Glib::Value*
classes in it, which is probably quiet beneficial because it is stuff a
C++ programmer would rarely want to use explicitly: they are mainly just
glue between the GObject C based type and object system and the native
C++ type and object system, and work behind the scenes.  Those who
really need them will know where to find them.

A GThread namespace is more based on function and could contain
Glib::Thread, Glib::ThreadPool, Glib::Cond, Glib::Mutex,
Glib::RecMutex, Glib::RWLock and so forth in it.  (By the way, I was
wrong in suggesting that these have separate documentation in glib -
unlike gobject they don't.  In glib, gthreads are separated out to make
it easier to provide separate windows and posix implementations, and
ditto gmodule.)

I don't feel especially strongly about it, just that if more use is to
be made of different namespaces in glibmm, which seems to me to be a
good idea, then there are other candidates apart from gio's dbus
implementation.

> >  the defining feature of course is that gio
> > contains vastly more code than would these others namespaces.
> 
> Yes, gio has a huge amount of API, particularly now that it has the
> GDBus stuff too. It feels like a special case.

gio sometimes seems to me to be becoming like a take-over bid.  Why is
glib's dbus implementation in there anyway?  OK it uses gio's io
library, but so do other things.  That may be one reason why it looks
like a special case.

> The separation does seem arbitrary sometimes though.
> 
> > However modularising glibmm is in my view a good thing, so Gio::DBus
> > sounds fine to me.  But why restrict this to just one subset of gio,
> > namely gdbus? As I say, there is a great deal more namespace
> > modularity which could sensibly be implemented in glib.
> 
> At the moment, I'm just moving them into a namespace. I assume that
> you are not proposing to move them into a separate shared library.

No, I was referring to source code and naming modularity, rather than
binary modularity.

Chris