Re: Plans for 2.8 - GNOME Managed Language Services?

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:

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]