Re: Plans for 2.8 - GNOME Managed Language Services?

[Murray Cumming <murrayc murrayc com>]

On Fri, 2004-03-26 at 18:07, Havoc Pennington wrote:
> 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
> > 
> > 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,

Oh, I thought you meant runtime introspection. Yes, the .defs file
format is quite well established, and mostly standardized in a spec.
Several (pygtk and gtkmm and others I think) use the same
header-file-scanner (h2defs.py). We do have different utilities to get
extra bits such as enum, properties, signals and vfuncs.

Having standard .defs files in the GTK+ tarballs would be helpful, but I
don't actually think it would make much practical difference to anyone.

>  and we've been discussing introspection metadata on the dbus
> list. If you put that together you could at least have a standard
> maintained-in-GTK+ way to generate bindings,

Note that a significant percentage of bindings code is hand-coded, or
tweaked into the right direction somehow, in order to make the most
perfect constructs for the particular library. For instance, C++ is very
close to C and probably the easiest binding to create, but unless you
choose a crippled subset of C++, you can't autogenerate/autointrospect
it all.

The .defs do make the rest much much easier though.

Of course, using a managed runtime would cripple most of the languages
that it supported, so you'd be solving part of this problem. But I'm not
sure that everyone would like that.

>  or even better enable
> dynamic bindings based on libffi, P/Invoke style approach.
> 
> I don't know, basically just look at how we can better automate bindings
> along the lines of XPCOM/UNO. Add some cheesy component-system style
> features to GObject.
> 
> I'm looking for practical easy steps forward here.

Yes. People don't know about it much, but the .defs were a quite massive
step forward around the GTK+ 2.0 time.

We do have a lot of bindings, and many are of high quality - we just
need to get them in-sync with the rest of GNOME so that we can feel safe
about using them. I'm doing what I can to make that happen.

Maybe more runtime introspection (listing objects and their methods, and
their parameters, for instance) might help maintainers of bindings for
dynamic languages, such as python. If so, let's have it. I'd like to
hear from them.

Sorry, I seem to have rambled without adding much to the discussion.

-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com