On Tue, 3 Jun 2008 18:52:33 +0200 Jean-Yves Lefort <jylefort brutele be> wrote: > On Tue, 3 Jun 2008 13:34:13 +0200 > Kristian Rietveld <kris imendio com> wrote: > > > 4. We will completely lose all means to simply access fields by just > > dereferencing the structure. Instead, we will start to use GObject > > properties to access this data much more often. Using g_object_[sg]et() > > can become a little tedious. Therefore we should introduce a couple of > > convenience accessors for GObject properties such as g_object_get_int(), > > *double(), *string(), etc. > > Because of the dynamic nature of the GObject property system, this > would also bring a substantial performance overhead, eg: > > - unnecessary dynamic lookup of a pspec whose name and details > are known at compile time > - unnecessary round-trip through GValue > - for non-virtual properties, unnecessary indirect call > - unnecessary switch in the global get_property/set_property, > as opposed to per-property accessors > - ... > > Have you ever considered switching to a static design? It would > eliminate the unnecessary dynamic overhead, and it would also make it > much easier to implement a GObject. That is, property declarations > would be put into a separate input file, which a simple GObject > compiler would use to generate the relevant C glue. > > Note that I don't propose to abandon the dynamic access functionality, > which is certainly useful and desirable in a number of specific > situations. I simply point out that the performance penalty of dynamic > access is unjustified for static use. Basically, something like this: http://doc.trolltech.com/4.4/properties.html When reading this and other Qt documents, one realizes that a large technological gap separates GLib/GTK+ and Qt. Fortunately, Imendio has impressive plans for GTK+ 3.0 (things that developers of client code have been wanting for years, such as the removal of deprecated code or the mangling of fields), so one can rest assured that this gap is going to be closed in no time. -- Jean-Yves Lefort <jylefort brutele be>
Attachment:
pgp10R03lDqe1.pgp
Description: PGP signature