Re: Introspection

[Dan Winship <danw novell com>]

On Tue, 2005-01-11 at 09:36 +0800, James Henstridge wrote:
> If an irregular function was required to use a widget, I'd hope that a 
> marshal function could be registered for it in the metadata, providing
> a simpler calling convention.

I don't think there are any cases (in glib/atk/pango/gtk at least) where
a varargs method is *required*. But there are functions like
gtk_dialog_new_with_buttons() that are just more convenient than their
alternatives. If the metadata can't describe how to wrap them
automatically, the binding maintainers may want to wrap them by hand, so
it is useful to have them explicitly pointed out.

> >Lots of methods use "GtkWidget *" as a parameter or return type when the
> >actual type required/returned is something more specific. The metadata
> >should indicate that.
> 
> Is this actually a problem though?  Even if you exclude the cases where 
> a more specific return type could have been used, a language binding is 
> going to want to pick the most specific wrapper class to represent the 
> value.  They could use the same logic here too

I'm not worried about run-time types, I'm worried about static type
signatures. Consider:

        GtkWidget* gtk_dialog_add_button        (GtkDialog   *dialog,
                                                 const gchar *button_text,
                                                 gint         response_id);

in gtk-sharp this gets wrapped as:

        public Gtk.Widget AddButton (string button_text, int response_id) {
        	...
        }

but really the return type should be Gtk.Button, because that's what the
method actually returns, and returning a superclass of the real return
type only makes sense in C, where upcasts aren't automatic. So the
metadata should indicate the "real" return type, and metadata consumers
can use that information as they see fit. (Pygtk and other
dynamically-typed-language bindings would probably not care at all.)

> (also, many functions 
> returning GtkWidget* are constructors, which would be handled slightly 
> differently anyway)

One of the places it comes up most actually is in the fields of compound
widgets. Eg:

        struct _GtkFileSelection
        {
          /*< private >*/
          GtkDialog parent_instance;
        
          /*< public >*/
          GtkWidget *dir_list;
          GtkWidget *file_list;
          GtkWidget *selection_entry;
          GtkWidget *selection_text;
          GtkWidget *main_vbox;
          GtkWidget *ok_button;
          ...

etc

-- Dan