Args interface (was New 'GObject')

[Karl Nelson <kenelson ece ucdavis edu>]

> > > Hrmm? I guess you are referring to the varargs interfaces in 
> > > GTK+ ... but those are going to be wrapped anyways by a
> > > language binding.
> > [...]
> > 
> > Yes, however, Guillaume has pointed out several places in the 
> > Gnome interface where this was the only way to access something.
> > Those places give us nightmares and thus we end up rewriting the
> > whole access functions.  
> 
> Hmmm, the only thing you seem to lose here is 
> 
>  a) automatic generation of binding glue
>  b) some amount of efficiency
> 
> And for a) it should be quite possible to automatically create
> argument-setters and getters from the results of querying the
> type system.
> 
> (It is a bit troublesome right now that some forms of type information,
> like methods signatures, are only available by header-file parsing,
> and other forms of type information, like signal and argument
> specifications, are only available as a runtime query. But
> it is still possible to discover everything if you are willing
> to compile and run a small query program as part of the 
> generation process. gtk-doc does this.

But where do we need to do this and where is there already a 
set_border_width?  Gtk-- could theoretically take all the
signals and methods from Gtk+ headers if it was intelligent
enough to figure out what was the intention of all the
declarations.  We can't make a script with level intelligence
so we have sorted those things out by hand.  

Fortunately, 90% of Gtk-- can be written by a code generator
after the sorting.  It is just that the number of patterns
in that code generator is very large because of the variants.
This all goes back to gtkprocess to generator header and
stubs to make the system all the more consistent.  (see
earlier reply to TimJ)

Wouldn't having the header come from the spec make it
so that spec was usable enough for all this info?

--Karl