Re: Plans for 2.8 - GNOME Managed Language Services?

[jamie <jamiemcc blueyonder co uk>]

On Fri, 2004-03-26 at 18:03, Soeren Sandmann wrote:
> Havoc Pennington <hp redhat com> writes:
> 
> > > > 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, 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, 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.
> 
> Could this be done better at the library level instead of the GObject
> level?
> 
> What if libraries exported a well-known function that returned a blob
> of data describing the entire library instead? So the data might
> contain some representation of basically the data in the header
> files. Dynamic languages could use this information directly, and
> gtkmm would least get a standardized way to generate the C++ headers.
> 
> The type system used in those blobs of data could include GObject as a
> primitive, so that bindings would know when they could use GObject
> introspection. The metadata format could be specified so that other
> types, like "C++-object" could be used as primitives.
> 
> > I'm looking for practical easy steps forward here.
> 
> More specifically I would suggest that C libraries GTK+ included a
> big, constant table of structs like
> 
>         typedef enum {
>                 C_INT,
>                 C_DOUBLE,
>                 C_VOID_PTR,
>                 G_OBJECT_PTR,
>                 ...
>                 C_VOID
>         } SimpleType
> 
>         struct {
>                 const char *name;
>                 SimpleType return_type;
>                 SimpleType arg_vector[5];
>         } SimpleFunction;
> 
>         struct {
>                 const char *name;
>                 int n_args;
>                 ComplexType *return_type;
>                 ComplexType *arg_vector[12];
>         } FullFunction;
> 
> etc (I am just making it up as I go). The blob of data would be binary
> for parsing speed, and there would be information about how to get rid
> of returned data (for the benefit of garbage collectors).
> 
> It wouldn't have to be terribly annoying for library writers. Every
> time they add new public API, they should update a big table
> somewhere with a new line looking something like those:
> 
>         ...
>         { G_CONSTRUCTOR, "GtkButton",
>           G_OBJECT, "gtk_button_new_with_label", G_OBJECT },
>         { G_METHOD, "GtkButton",
>           VOID, "gtk_button_set_label", C_CHAR_PTR },
>         ...
> 
> You could imagine adding stuff like documentation there too. All the
> blob-related processing could be in a separate library, so that this
> binding metadata could then be used across desktops. In that case
> support for more primitive types, like QObject, MozillaObject, ...,
> wold be needed. The key would be to make sure the type system was
> extendable in a compatible way.
> 
> Bindings would then open the library and call the function
> 
>         Blob *describe_this_library (void);
> 
> to find out what they could do with it.
> 
> Actually this is quite similar to the old HUB paper that you and Owen
> wrote, but simpler and there is a more immediate benefit for a project
> to adobt it ("get language bindings almost for free").

That could work but you would need to support inheritance for describing
the library. I.E. if I subclass a new GTKEntry widget, the description
would need to contain the interface for my new widget + GTKEntry +
GTKWidget + GTKObject + GObject.

As you can see this would be quite large and annoying to manually enter
so it would need adapting so that all the descriptions of all ancestors
are merged automatically (you would need to include an ancestor field to
the description).

jamie.



> 
> 
> Søren
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
>