On Sun, 2004-03-28 at 11:31, muppet wrote: > > There aren't many GTK+ functions that take only basic C types. It > > wouldn't be a very useful if it just told us that function > > do_something() took 4 void* parameters and returned a void*. > > There are many ill-behaved objects and libraries which use > G_TYPE_POINTER for property types. This makes these properties > essentially unbindable for non-C languages. For examples, > libgnomecanvas does this with the path property of a GnomeCanvasBpath: > http://bugzilla.gnome.org/show_bug.cgi?id=116734 > > I once considered simply removing all of the property getters and > setters from the bindings, as that would decrease the API size (and > therefore binding size) immensely. There's no reason for most language bindings to have both support for GObject properties and setters and getters; the main reason we do it in C is that property setting is not type safe, but there isn't even a big performance advantage for going through the setter/getter; the property still has to be looked up to do change notification. [...] > >> you can then do: > >> > >> g_object_get_method(gobj, "some_foo_method") to get the function > >> pointer, > > I can't help thinking that this could be done in an add-on library (or > magically auto-loaded gmodule) to avoid adding a runtime memory hit to > C/C++ apps and libraries that don't use it. It would be binary (or > possibly xml or ascii) metadata and an API that wraps GClosures around > methods. The important thing to do to avoid memory and relocation bloat is to make the typelib for entire files or maybe even entire libraries a single large binary blob, then it will just be left on disk until needed.. You'd only need something like: g_type_set_type_info_location (GTK_TYPE_WIDGET, _gtk_type_info); for each type. (You could reduce things even more with dladdr(), but then you get into portability issues.) > The important part would be the metadata. In order to get it right, > you'd be best off forcing the C library projects to eat their own > dogfood by generating the C headers and possibly even documentation > directly from the API specification metadata. Yes, i realize that's a > pipe dream. :-( If we are generating the metadata based off the headers, then you can't also generate the headers from the metadata... Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part