Re: Plans for 2.8 - GNOME Managed Language Services?

[Mike Hearn <mike navi cx>]

On Fri, 26 Mar 2004 12:07:17 -0500, Havoc Pennington wrote:
> 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.

While GObject isn't perfect, it's a lot better than COM which sustained
code sharing on the Win32 platform for over a decade (and arguably still
does given the slow rate of .NET adoption there). I think we can take it
as given that there's not going to be standardisation on any one object
model and ABI (which is what the .NET CLI is, to some extent) anytime
soon, so extending/rewriting GObject to have some extra abilities is
definitely a good step forward. Otherwise no matter what amazing new
language becomes popular people will still write libraries in C to get
maximum user base.

Things that would be really useful to have:

* Introspection. Soerens idea is a good one that I've been tossing around
for a while, though I can't see any reason why it would have to be hand
written. Possible a better approach than sticking a blob into binaries is
to have an official GObject reflection interface along with a list of type
registration functions. IE you could do:

registration_funcs = dlsym(whatever, "_public_types_");

where registration_funcs is an array of _get_type functions, and then have
a GInterface on those objects/types that implements reflection. So you can
take an arbitrary DSO and build a database of all the types and method
addresses etc for each object. 

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)

This is useful for a lot of things: bearing in mind that while it's
acceptable, even expected, to spend a lot of time tweaking and perfecting
the API for something like GTK+, there are *many* projects that could
benefit from exposing their objects to other platforms with "zero effort",
by which I mean they create their object, perhaps provide extra
hints/metadata about it and then other people can bind it automatically
into the platform of their choice without the original object author being
aware of that.

If I write a class to do something useful, I want it to be useful for
everybody! This has traditionally not been easy because there is no
shared object model. COM is so primitive (as an OM) it barely deserves the
O in its name, GObject somewhat less so.

Just taking an existing parser like h2defs or the GTK# one and then
building a converter to C struct initialisers would be a good start.

* Ability to bind objects from other languages -> GObject.
Loading and reflecting a Python object into C should be an interesting
project for somebody that wouldn't be too hard - the Python object model,
with the exception of signals (which afaik is not a part of any native
language OM) is a superset of GObject so it should not be too painful as
long as some basic rules are followed. You could then write a Python class
and run the automatic generator program on it to spit out a
libmegaobject.so.0 file which contains the GObject skeletons for the
class, along with code that implements the reflection interfaces.

* 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

you can then do:

g_object_get_method(gobj, "some_foo_method") to get the function pointer,

in other words, with a few API calls you can grab any object from a
dynamic-enough runtime and start calling methods on it from another
dynamic runtime as well as compiling it into static code for languages
like C++ (and maybe java/c#). Or maybe a g_object_call function...

Of course things would never be that easy in practice *but* it would give
us all some wiggle room. 

OK, time to crash out
bye -mike