Re: custom functions in introspection typelibs

["Havoc Pennington" <hp pobox com>]

Hi,

On Sat, Sep 27, 2008 at 5:05 PM, Colin Walters <walters verbum org> wrote:
> Well...this needs to be weighed against the other option, which is
> having the overrides mechanism be entirely contained within the
> bindings.

Right, that's what I started trying to do as I mentioned. However, the
issue is that <class name="Widget"> can't be in two different .gir
files without creating some new complexity.

For overrides that make sense for all bindings, I think we should
consider gir-repository to be a "shared binding" or shared piece of
all bindings, and include the overrides there.

gir-repository is not part of gobject-introspection, it's the shared
part of 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).

I don't know which module these things should be in, but I think they
are useful to have in the "G" stack. Aside from bindings, an example
use-case is writing a dynamic marshaler to replace glib-genmarshal
static marshalers.

It is not a big deal for any binding to cut-and-paste from
gobject-introspection probably, but I think as soon as a few bindings
are using this, or some non-binding use is found, there will be demand
to factor them out and stick them someplace.

They probably do belong in glib proper, not gobject-introspection.

> 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).

One counterargument is that there's substantial code to write to go
from a GIFieldInfo to these language-specific FFI layers. Something
like:

  void g_field_info_get_value(GIFieldInfo *info, void *instance,
GArgument *value_out)
and
  gsize g_boxed_info_get_size(GIBoxedInfo *info)

would be more convenient than hand-rolling stuff, I think. But, this
is not a huge deal for me, I can cut-and-paste what's in g-i now.

> 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
>

I like the inject solution but not the libjscustom.so ... this means
the js bindings would conflict with gir-repository (both would be
installing Clutter.gir and the Clutter typelib).

I think the injection and the custom .so should be in gir-repository,
and that the custom .so should be per-typelib to avoid extra
dependencies. (i.e. the custom .so for GLib should not drag in GTK)

Perhaps gir-repository should be designed to be "sucked in" to each
binding, that would not be awful, but it does mean we need some kind
of binding-specific search path for typelibs and that we'd have
multiple copies of each typelib (per-binding).

>> Correct fix: add support to gobject-itrospection for accessing struct fields.
>
> If you have an FFI layer you get this.

Note, though, libffi itself doesn't have this afaict. It looks to me
like struct field access (and struct size determination) have to be
coded from scratch, or at least massaged into existence by
de-pythonizing python ctypes code or some other existing codebase.

The python ctypes source for struct access is not huge, but it's not
trivial, because it has a good bit of #ifdef and because bitfields
appear to be a pain in the ass.

So in short there's no existing nice C library that does this. It
makes sense to me to include it in glib or gobject-introspection or
something.

The libffi API hugely sucks, too, but we can ignore that aesthetic
issue for the sake of discussion ;-)

>> * 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.

The specific example here (passing pixbuf pixels without copying them
through a non-C string) I think is probably common to all bindings and
is effectively needed to make the Clutter API practical outside of C.
I'm not sure it should be in gir-repository without getting Clutter
upstream agreement to eventually include it, but given that agreement,
including it makes sense.

The problem here can't be solved outside of C in JavaScript at least;
maybe it could be in languages with unsafe pointers that can
effectively just write the raw pointer handling in the language.

Havoc