Re: Plans for 2.8 - GNOME Managed Language Services?

[Soeren Sandmann <sandmann daimi au dk>]

Havoc Pennington <hp redhat com> writes:

> > > My suggestion if we want to do something in 2.8 and we can't get people
> > > behind "open source Java subset" is:
> > >  - make full introspection data on the GTK+ API more formally part of 
> > >    GTK+, so language bindings aren't maintaining this themselves
> > 
> > I'm not sure what you mean here? Do you just mean GObject properties?
> 
> Well, I'm not 100% sure either - but several of the bindings seem to
> have header-file-scanners that create a description of all the
> functions, and we've been discussing introspection metadata on the dbus
> list. If you put that together you could at least have a standard
> maintained-in-GTK+ way to generate bindings, or even better enable
> dynamic bindings based on libffi, P/Invoke style approach.
> 
> I don't know, basically just look at how we can better automate bindings
> along the lines of XPCOM/UNO. Add some cheesy component-system style
> features to GObject.

Could this be done better at the library level instead of the GObject
level?

What if libraries exported a well-known function that returned a blob
of data describing the entire library instead? So the data might
contain some representation of basically the data in the header
files. Dynamic languages could use this information directly, and
gtkmm would least get a standardized way to generate the C++ headers.

The type system used in those blobs of data could include GObject as a
primitive, so that bindings would know when they could use GObject
introspection. The metadata format could be specified so that other
types, like "C++-object" could be used as primitives.

> I'm looking for practical easy steps forward here.

More specifically I would suggest that C libraries GTK+ included a
big, constant table of structs like

        typedef enum {
                C_INT,
                C_DOUBLE,
                C_VOID_PTR,
                G_OBJECT_PTR,
                ...
                C_VOID
        } SimpleType

        struct {
                const char *name;
                SimpleType return_type;
                SimpleType arg_vector[5];
        } SimpleFunction;

        struct {
                const char *name;
                int n_args;
                ComplexType *return_type;
                ComplexType *arg_vector[12];
        } FullFunction;

etc (I am just making it up as I go). The blob of data would be binary
for parsing speed, and there would be information about how to get rid
of returned data (for the benefit of garbage collectors).

It wouldn't have to be terribly annoying for library writers. Every
time they add new public API, they should update a big table
somewhere with a new line looking something like those:

        ...
        { G_CONSTRUCTOR, "GtkButton",
          G_OBJECT, "gtk_button_new_with_label", G_OBJECT },
        { G_METHOD, "GtkButton",
          VOID, "gtk_button_set_label", C_CHAR_PTR },
        ...

You could imagine adding stuff like documentation there too. All the
blob-related processing could be in a separate library, so that this
binding metadata could then be used across desktops. In that case
support for more primitive types, like QObject, MozillaObject, ...,
wold be needed. The key would be to make sure the type system was
extendable in a compatible way.

Bindings would then open the library and call the function

        Blob *describe_this_library (void);

to find out what they could do with it.

Actually this is quite similar to the old HUB paper that you and Owen
wrote, but simpler and there is a more immediate benefit for a project
to adobt it ("get language bindings almost for free").


Søren