Re: custom functions in introspection typelibs

["Colin Walters" <walters verbum org>]

On Sat, Sep 27, 2008 at 4:10 PM, Havoc Pennington <hp pobox com> wrote:

> In the long term, we can probably remove the need for any custom
> functions, but in the short term we have the idea that gir-repository
> allows us to fix any bindings issue without waiting up to 2 years for
> new upstream releases to percolate into all the major distributions
> (and for users to have upgraded their distribution).

I'm fine with having gir-repository contain workarounds, but remember that

1) Committing to gir-repository SVN doesn't help OS vendors because
they generally will be consuming fixed release points (currently
tarballs), just like GTK+.
2) In the long term (I hope within a year) we do want to kill
gir-repository and integrate the gir build process into modules

Once we do move into the modules, if you're in a position to consume
gir-repository SVN (i.e. the "developer jhbuild" and "Poky-like
targeted product" scenarios), it should also be possible to consume
SVN/git (or branches thereof) of the individual component modules like
GTK+, clutter etc. so fixes can go into there.

> Ideally, bindings
> can track bleeding-edge gir-repository, and thus put all the special
> case workarounds in that common location, instead of having to do it
> in each binding.

Right, but again we really want this "common location" to be the
module itself in the long term.  We're not yet ready for this since a
lot of things are still in development like the annotation syntax,
etc., but it is worth keeping this in mind.

> In the short term, I think it's practical to support a custom
> functions mechanism in gobject-introspection.

Well...this needs to be weighed against the other option, which is
having the overrides mechanism be entirely contained within the
bindings.  I'm increasingly thinking that it makes more sense for
gobject-introspection to be solely an information source, instead of
information + runtime binding/mapping mechanisms.  Concretely, this
means removing g_function_info_invoke (and thus no GArgument).

While superficially it seems to make sense to have APIs like
g_function_info_invoke that can be shared between C interfaces like
pybank, spidermonkey, and reflective invocation from C, for the first
two it becomes problematic because in the more complex cases (think
about the array+length mapping cases) you really need binding-specific
intelligence in the invocation layer (such as how to extract the
length of an array argument).  So it becomes just a limited FFI
wrapper with a "G" in front of the types, which isn't very useful.
Also practically speaking almost every runtime already has a FFI-like
layer (Python has ctypes, Ruby has ruby-ffi, Java (JVM) has JNA, .NET
has P/Invoke, OCaml has "external" builtin to the language); it's just
JavaScript that lacks it (in the same way it basically doesn't have
any libraries at all).

> I think my opinion is that we should allow multiple library="" in a typelib.

Allowing multiple library= isn't hard.  But I don't think you need
this.  Probably the simplest is to write a script which can inject
things into a GIR.  Then you recompile the GIR into a .typelib, which
shouldn't care that you are defining some symbols that don't actually
exist in the referenced library.

> Havoc
>
> Examples of custom functions:
>
> * custom functions that add accessors, e.g.
> gint
> clutter_geometry_get_x(ClutterGeometry *geometry)
> {
>    return geometry->x;
> }

So concretely for this one, you could have your libjscustom.so.  You
put this function (and all your other custom functions) inside there.
Then you do:

g-ir-inject Clutter.gir ClutterAdditions.xml

Where ClutterAdditions.xml looks like this:

<?xml version="1.0"?>
<overrides>
 <inject path="/repository/namespace/class[ name='Geometry']">
   <method name="get_x" c:symbol="clutter_geometry_get_x">
     <return-value>
       <type name="int" c:type="gint"/>
     </return-value>
   </method>
  </inject>
  <inject> ... </inject>
</overrides>

Basically g-ir-inject takes a list of (xpath, XML) and inserts it.

> Correct fix: add support to gobject-itrospection for accessing struct fields.

If you have an FFI layer you get this.

> * custom functions that add boxed constructors, e.g.
> ClutterColor*
> clutter_color_new (void)
> {
>    return g_slice_new0(ClutterColor);
> }
>
> Correct fix: add support to gobject-introspection for knowing
> sizeof(ClutterColor)

Using FFI you can get this information (as I do indirectly using JNA in JGIR).

>
> * custom functions that do something that's much easier/better in C
> than in other languages:

Now for things like this, I think there is a clear need for each
binding to have a custom library layer.  This is different from the
first layer because you can write this layer in your binding language.

> Correct fix: have upstream register the type; but, custom function is
> the only possible fix short-term (sub-2-years)

It's not the only possible fix - you can also point g-ir-scanner at a
Clutter git branch where you've made changes.

Again - having gir-repository workarounds *does not help* with that
2-years timeframe because no OS vendors are shipping
gobject-introspection or gir-repository, and I would oppose them doing
so right now because we aren't API/ABI stable.  jhbuild (or
fundamentally, using SVN/git branches) is the right way to develop
against in-progress libraries and tools and also to encourage
upstreaming of changes.