Re: GObject-Introspection

On Mon, 2008-09-01 at 16:33 +0200, Johan Dahlin wrote:
> There were a couple of reasons to switching to xml over s-expressions.
> The primary one is that XML is more popular, most modern languages
> have parsers builtin which will make it easier to write tools upon it.
> Other reasons includes that xml is more flexible.

As someone who is struggling with nested quotes and braces in gtkmm's
perl-based .defs parser, I am glad that the future offers XML. Thanks.

> The GIR XML is meant to be processed & modified by tools, not human beings.
> > And presumably, you would still have to hand-write large parts of the
> > bindings using something analogous to PyGTK's overrides. I can't think
> > of any automagic that would turn this C function:
> > 
> >   void gtk_label_get (GtkLabel *label, char **text);
> We solve that by adding annotations in the gtk-doc comment.
> The specific case you mentioned will have something like this:
> /**
>   * gtk_label_get
>   * @label: the label
>   * @text: (out): the text of the label
>   */
> Which will in turn be create the following XML snippet:
> <parameter name="text" direction="out">
>    <type name="string"/>
> </parameter>
> The idea is to annotate most of the available API so almost the complete 
> bindings can done without manually overriding parts.

As I've told Johan, this won't be possible for significant amounts of
the API, because human thought really is required to make truly usable
APIs. And I worry that the auto-generation will create bad API that will
be declared stable and unbreakable without a maintainer ever even
looking at it.

But we won't have this problem with gtkmm because we hand-define the API
that should exist and only generate the intermediate _implementation_.

murrayc murrayc com

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