Re: Plans for 2.8 - GNOME Managed Language Services?

[muppet <scott asofyet org>]

On Sunday, March 28, 2004, at 10:40 AM, Murray Cumming wrote:

> On Sat, 2004-03-27 at 01:23, Mike Hearn wrote:
> [with gratuitous snipping]
> > As Soeren said it needn't be GType/GObject specific, a lighter weight 
> > abstraction over basic C types could be useful as well, if only for 
> > quickly strapping it onto existing code (C_ARRAY, C_STRUCT, C_STRING 
> > etc)
>
> 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.


> Note that there already is a gtype-based system like this for signals, 
> which gtkmm, python, and probably others use, though gtkmm doesn't use 
> it at runtime.

Perl and Python use it extensively, basically allowing a single 
marshaler (or small set of marshalers) to handle all GClosures.


> > * Not required but would be cool, ability to do all that 
> > automatically for objects from dynamic languages.
> >
> > What I mean is there should be a generic:
> >
> > GObject *python_get_gobject_from_class(PyObject *pyobj)
> >
> > method, which:
> >
> >   - reflects the python object and creates a new GType
> >   - construct assembly thunks for the methods, init the signals
> >     and so on, ie basically build the object at runtime
> >   - delegates the reflection interfaces to a generic implementation

Actually, for dynamic languages you may not need to initialize all of 
this stuff at startup, but just when you are actually ready to use it.  
In Perl, for example, all methods would go through AUTOLOAD, and the 
autoloader mechanism would look up the method on first use and cache it 
for later.


> > 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 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.  :-(



--
"it's hard to be eventful when you have this much style."
   - me, rationalizing yet another night of sitting at home.