Re: Why do constructors return GtkWidget?

[Tristan Van Berkom <tvb gnome org>]

On Wed, Nov 4, 2009 at 4:11 PM, Andrew Paprocki <andrew ishiboo com> wrote:
> 2009/11/4 Sven Herzberg <herzi gnome-de org>:
>> In my opinion the GTK+ way is really nice (just compare it to GStreamers
>> element factory, which behaves essentially the same way, just as
>> GnomeCanvas' gnome_canvas_item_new() function). It's really nice to get
>> those items returned as the generic type (but Cody told you already).
>
> We've found the generic type return to be harmful because it prevents
> writing tools to find simple code bugs. Tools that analyze types can
> ensure that GTK_FOO(widget) is a valid cast if the code previously did
> something like:
>
> GtkFoo *widget = gtk_foo_new();
>
> It is much harder to do this when the constructor returns a GtkWidget.
> Similarly, APIs that expect certain classes should take those classes
> explicitly instead of GtkWidget (this is less commonly found). E.g.:
>
> void i_only_take_a_gtk_foo(GtkWidget *widget)
>

I guess the question boils down to this:

  Could we really propose that everybody should rewrite massive portions
  of their UI code (basically *all* the GtkWidget casting code), for a
  slightly better type safety at compile time when using GTK+ directly from
  C code ?

Maybe a better direction to push would be, adding some gtk-doc annotations
to make sure the resulting gobject-introspection data is more rich and
accurate ?
(maybe the gir for GTK+ can be good enough to bridge the gap for said tools
that dont know how to handle generic types returned from contructors, probably
can help)

Regards,
      -Tristan