Re: Why do constructors return GtkWidget?
- From: Tristan Van Berkom <tvb gnome org>
- To: Andrew Paprocki <andrew ishiboo com>
- Cc: Sven Herzberg <herzi gnome-de org>, gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: Why do constructors return GtkWidget?
- Date: Wed, 4 Nov 2009 16:33:21 -0200
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
(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
] [Thread Prev