Re: Plans for 2.8 - GNOME Managed Language Services?

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBAZwFYS+2LB0B90LERAm4vAKDVGgL3DwaQ64Yp5ZvCPJt5CEKlZQCfYaTZ
GX2/opyEqupbuTRaCXc8O90=
=rtx1
-----END PGP SIGNATURE-----