GObject bindings continued...

[Mike Kestner]

[Not subscribed, so please CC me on replies.]

> From: Havoc Pennington <hp at redhat.com>
> Date: Thu, 18 Mar 2004 18:11:56 -0500
> 
> On Wed, 2004-03-17 at 09:51, Mikael Hallendal wrote:
> > 
> > So to provide introspection of methods the plan is to have a tool to
> > parse the header files and produce the introspection XML data from that.

FWIW, I've already written this tool for Gtk# using perl and the
perl-libXML bindings.  It parses C headers and source to produce an XML
representation of the Fields, Signals, Properties, Methods and Virtual
Class Methods for GObjects in addition to all the other struct and enum
types in the headers.  If it's not exactly what you want, it's certainly
closer than starting from scratch, if you don't mind hacking on a set of
perl scripts.  

> > Since the header files for C/C++ lack all the information needed to
> > produce this data what is the plan (and how is it done in QT?). Is it
> > done by marking up the header files with special comments that are used
> > to no whether a method argument is an in/out argument and such?
> 
> My thought (and essentially what Qt does) is to just figure it out from
> the C, and programmers just have to write C that the tool understands. 
> Then magic comments can annotate/correct. Pretty much exactly the way we
> do language bindings and gtk-doc today.

This would take some significantly more stringent coding standards than
seem to exist today.  See below:

> For example, if a method takes a struct argument then the tool will
> complain and bail out. If it takes "const char*" then that's "in string"
> and if it takes "char **" then that's "out string"

Or it might be string[].  Similar problems exist around things like:

void foo (gint *bar);

Is bar an out int, ref int, or an array of ints?  We're still wrestling
with all of this for Gtk#.  The approach we've taken is to default to
the out param and alter the xml using another file of rules which we
hand-code as we discover via audit/use any params that are really arrays
or refs. So we have a fair amount of knowledge accumulated already that
might be reusable here as well. 

> > Adding full introspection to the GObject layer sounds like something we
> > want anyway since it would help when binding it to other languages since
> > from what I can see all bindings effort duplicate these efforts of
> > tagging up method calls arguments for in/out etc.       
> > 
> > Does anyone know how interested GObject maintainers would be to add this
> > to GObject itself so we don't have to maintain this in D-BUS?
> 
> I haven't proposed it, though it might be sort of nice.

The thing I'm really missing right now is class method introspection. 
There really is no way to intelligently override and chain to virtual
methods now.  Basically, clones of g_signal_override_class_closure and
g_signal_chain_from_overridden.  I don't know if you guys will trip over
this for your application as well.

-- 
Mike Kestner <mkestner at ximian.com>