Re: Third draft (was Re: defs files)

[Havoc Pennington <hp redhat com>]

Paolo Molaro <lupus@lettere.unipd.it> writes:
> 
> I don't see the need for this module stuff: we can just name
> a GtkCList object GtkCList and use the prefix Gtk. Also
> note that some already established bindings may have different
> module names then the obvious ones (and that cannot be changed
> as it breaks source compatibility). But maybe it's just me:
> creating the function bindings from .defs files is nice to
> get a binding started, but after that it's only compile-time 
> overhead.
> 

The idea is to always autogenerate the majority of your binding code,
instead of having to do it manually.


> This is not enough as a string returned from a func could be
> malloced or static.
>

Right there's a flag in the (function) definition that tells you this.
 
 
> I don't know if this will be any use for automated creation of
> the binding: could you provide and example usage of c-declaration?
>

The C++ bindings can use them, while high-level bindings probably
don't want to wrap stuff that requires a c-declaration.
 
> Available at runtime once you know how to init a class, see later.
>

But you might want to generate a non-dynamic wrapper for them.
Wrappers that don't use this can just ignore it of course.
 
> I'd like also to have version information in the defs file.
> 
> I think we need two different defs files:
> 1) one with only the info that cannot be queried at runtime from gtk
>    (object names with their class creation functions, enum/flag names, 
>    other type descriptions, etc).
> 2) a defs with function descriptions.
> 
> A lot of the info that you want to put in the defs file would be
> better queried from the gtk you're going to link with or you're going
> to get out of date pretty soon.
> 

I think language bindings should work as follows:
 - whenever possible, use runtime information
 - failing that, autogenerate the code from the latest defs file
 - failing that, manually write the code

The "thicker" a wrapper is, the more manual code is required. For
example, Gtk-- requires a lot of manual code. Sugar requires only 20
lines or so of manual code.

A wrapper that compiles statically (like most C++ wrappers) can't
really use the runtime information so needs to autogenerate signals,
etc. from the defs file.

Havoc