Re: Adding full introspection information (#139486)

[Maciej Katafiasz <mnews22 wp pl>]

Dnia 06-11-2004, sob o godzinie 00:27 -0500, Havoc Pennington napisał:
> > >    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.

Well, yes and no. Manual overrides are there because .defs format is
insufficient, which is because we don't embed enough info (can-return-
null for example) for .defs to be complete. The task is to identify and
complete missing bits, and then to create form appropriate to embed it
and directly use at runtime. And that's precisely the scope of
introspection bug. I believe it is doable. Also, GObject isn't any
random API, it was rather carefully designed to be easily bindable, and
that succeeded, resulting in bound APIs behaving predictably and with
few irregularities in there. That gives hope that fully automatic
binding is possible as well.

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

Hmm, not entirely true. That is, existing APIs are not introspectable
because they, ugh, lack full introspection. However, that's matter of
adding that info. Once its there, existing APIs are bindable, as is
shown by existing bindings. Then, the resulting APIs will be
introspectable + autobindable

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

Yeah. But we aren't there to support *arbitrary* APIs. We're only gonna
support GObject APIs, and that's big difference (well, yeah, I know some
libraries <cough>gnome-vfs</cough> use custom structs. That complicates
the matters a bit. But still, that's far from arbitrary C API)

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

C mapping is already there. What lacks is method to get full info about
that mapping for anyone who isn't C

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

We already have "conceptual object system that can be instantiated in
multiple languages". We only have discrepancy between support in it for
C and $any_other_lang

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

Again, due to goal of bindability GObject APIs already follow well-
defined set of conventions. The problem here is not that APIs are wrong,
but that they are undiscoverable for bindings without using facilities
not available at runtime

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

Hmm, take .NET for example. Now imagine it has everything it does have,
only introspection stuff gets stripped, and C# gets special place of the
language that every other is bound to. Existing APIs, written in C#,
would be almost the same, as language features almost didn't change.
Common type system is also there, so you can still operate x-language,
you just aren't able to learn what APIs are there, and need someone to
manually tell you. That is where GObject is today. Now add
introspection. That's where we want it to be :)

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 wp pl>
         http://mathrick.org