Re: Adding full introspection information (#139486)

[Havoc Pennington <hp redhat com>]

On Sat, 2004-11-06 at 01:33 +0100, Maciej Katafiasz wrote:
> 
> >    Question: are *any* of the current language bindings
> >    100% autogenerated? I think all of them hand code a 
> >    lot of things, even the ones that autogenerate most 
> >    of the GObject wrappers.
> 
> No, currently they are hand-written in large part. Generating bulk code
> from .defs is step one, writing manual overrides for places needing
> special attention (which currently are numerous, due to the lack of
> enough info in .defs, which stems from lack of enough info in code /
> markup) is second

My basic point is that if none of the language bindings is 100%
autogenerated, despite many years of work... you're setting a high bar
for the introspection implementation if you have the goal of
introspecting the *existing* glib/pango/gtk APIs in full.
After all, anything you could conceivably do in an introspection
mechanism could have been done in .defs, pretty much. And nobody has
really cracked the problem yet.

I think the right goal for the introspection mechanism is that you
*could* write reasonable APIs doing the same thing as pango/gtk that
would be 100% introspectable and auto-bindable. Not that the *existing*
pango/gtk API be 100% introspectable.

My guess: the difference in complexity between "support introspection of
C APIs designed for it" and "support introspection of arbitrary C APIs"
is enormous. Maybe not, but I bet I'm right.

What I'd do is pretty much just copy the semantics of Java/C#, create a
C mapping for objects/signals/methods/etc. And support introspection of
objects written using the C mapping.

> > Anyhow, I would argue for KISS; we don't need the ultimate object
> > system, and I'd also punt on automatic language bindings for all of
> > glib/pango/gtk. We just need a simple way to write automatically
> > remotable/bindable objects, which probably allows us to *mostly*
> > automate the language bindings.
> 
> Well, in the case of language bindings, there's very big difference
> between "99.999% automated" and "100% automated and the very moment you
> write it". 

I agree completely, and that's why trying to bind the *existing*
pango/gtk APIs is not the right goal for an introspection mechanism.
You should assume that to get to 100%, without a crazy-complicated
introspection mechanism, the library has to be written using the "C
binding" of a conceptual object system that can be instantiated in
multiple languages.

I would define the problem as introspecting a properly-written GObject
(and any associated/auxiliary/POD types), if and only if the
introspected API conforms to certain conventions. Those conventions are
essentially "the API could be (or is) generated from IDL" and the IDL
should be relatively sane/simple, should not contain all the funky
special cases found in .defs files.

I would not define the problem as introspecting the existing APIs in
full.

Havoc