Re: Plans for 2.8 - GNOME Managed Language Services?

["muppet" <scott asofyet org>]

Havoc Pennington said:
> On Fri, 2004-03-26 at 11:48, Murray Cumming wrote:
>> On Fri, 2004-03-26 at 16:55, Havoc Pennington wrote:
>> > My suggestion if we want to do something in 2.8 and we can't get people
>> > behind "open source Java subset" is:
>> >  - make full introspection data on the GTK+ API more formally part of
>> >    GTK+, so language bindings aren't maintaining this themselves

Hear, hear!


>> I'm not sure what you mean here? Do you just mean GObject properties?
>
> Well, I'm not 100% sure either - but several of the bindings seem to
> have header-file-scanners that create a description of all the
> functions, and we've been discussing introspection metadata on the dbus
> list.

Gtk2-Perl does not use the .defs files for three reasons:

1) they are not maintained as part of gtk+ (or, in general, the upstream
library).

2) they[1] do not include all of the necessary metadata (e.g., can this
function return NULL?  who owns the return value?  what vfuncs are available
and what are their signatures?  what are the types of the objects *inside* a
GList or GSList?  etc...).

3) Perl's own XS extension "language" is essentially a combination of defs +
overrides, anyway.  In most cases, the xsub declaration is just the C
function's ANSI prototype, and the standardized Perl toolchain does the rest;
we need custom glue code in places where we need to translate between C-ish
and Perl-ish idioms (GList/array => list returns, default parameters, GErrors
=> exceptions, etc).


Without 1) we'd be forced to do 2) ourselves, making 3) a lot of work for
little reward; so we chose to forego the defs and just go at it directly.  The
result -- we got stable, very featureful bindings in under twelve months, with
a lot of hard work from a small group of people.

If gtk+ (and all the other gnome libraries) included defs files (with all the
extra metadata), we'd have uniform API across all bindings, and we (gtk2-perl)
would have no further reason not to use the defs files.




[1] i'm speaking here of pygtk's defs files.  i gave a once-over to gtkmm's
defs files shortly before giving up on the idea, and have not looked since.

-- 
muppet <scott at asofyet dot org>