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. 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
