Re: glibmm: Creating a DBus namespace?

[Murray Cumming <murrayc murrayc com>]

On Wed, 2011-02-16 at 10:51 +0000, Chris Vine wrote:
> 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.

Yes, I see the value in splitting that of into its own namespace and
shared library.

> 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.

Thanks. That sounds good too.

>   (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.

Apparently other parts of gio needs to use GDBus*, and GDBus probably
uses gio, so it had to go in there all together.

> > 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.


-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com