Re: defs files

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes: 
> hm, i find especially the argument thingy a bit confusing, because you
> use the symbol "argument" for GtkArgs and for function arguments.

Fixed, renamed object arguments to (object-argument)

> also on function arguments, you don't specify whether tehy are in or
> out, need to be freed etc.

Added "inoutness" attribute to the type. So type aliases would be 
in-string out-string broken-in-string really-const-return-string etc.

I don't like the totally-abstract-from-C types in the current defs
files; it breaks on arguments like GtkWidget**, const GdkColor*, 
structs-by-value, etc. gnome-python just punts and manually wraps or
doesn't wrap at all functions with these "weird" arguments. Plus most
of the time you are just stripping the "g" off of a glib type.

So instead my proposal is:

 - normally just use the C type, s/ /-/g
    (type
       (alias const-gchar*)
       (c-name const-gchar*)) ;; I guess you could put "in" on this but
                              ;; it's obvious anyway...

 - otherwise make up a type for special cases
    (type
       (alias broken-const-string)
       (c-name gchar*)
       (inoutness in))

I don't know. My code generator for Sugar would just special-case
broken-const-string and ignore the inoutness attribute.

I can see more purpose to in-out specifiers on widgets so bindings can
for example use const on widgets, but unfortunately there is no way to
autogenerate that information, and I don't want to look at 2,000
functions and decide if the widget args are really const or not. :-)

> since a bunch of similar discussion has been going on at the end of 1997,
> (and the messages don't seem to be online anymore) i dug in my archives
> and exported the relevant thread.
> 
> attached is a gzipped unix-mail folder containing this thread, you might
> find it interesting in regards to argument specifications and object methods.
> 

Thanks. I think some of the stuff people are talking about there
requires a bit more manual tweaking than I want to do; I want to do a
pretty much autogenerated-by-perl-script defs file.

For example I see no way to get the mutator/accessor information by
scanning, unless you just assume that all functions set_foo are
mutators for "foo" and all functions get_foo are accessors for foo.
Which works maybe most of the time but there are plenty of exceptions
(first of all any get/set functions with more than two args).

Havoc