On Wed, 2011-02-16 at 10:51 +0000, Chris Vine wrote: > On Wed, 16 Feb 2011 10:54:20 +0100 > Murray Cumming <[email protected]> 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. -- [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
