Why do constructors return GtkWidget?

[Javier Jardón]

Hello,

I'd like to continue the discussion here of thread [1] from gtk-app-devel-list:

The question: why is it normal for GTK widget "constructors" to return
GtkWidget and not their real type?

For instance I would expect:

   gtk_menu_item_new ()

To return GtkMenuItem*. But it doesn't, it returns GtkWidget*.
IMHO is much clear that constructors return their real type, instead
GtkWidget. But maybe there is a technical reason for this.

Can someone give me some light about this?

Thank you for your responses,

PD: If there is not technical reasons, maybe we can change this for
GTK+ 3 (or 4 ;)), as I think a change like this will break the 2.x
ABI.

[1] http://mail.gnome.org/archives/gtk-app-devel-list/2009-September/msg00023.html
--
Javier Jardón Cabezas
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Cody Russell-2]

On Wed, 2009-11-04 at 06:23 +0100, Javier Jardón wrote:

> The question: why is it normal for GTK widget "constructors" to return
> GtkWidget and not their real type?
>
> For instance I would expect:
>
>    gtk_menu_item_new ()
>
> To return GtkMenuItem*. But it doesn't, it returns GtkWidget*.
> IMHO is much clear that constructors return their real type, instead
> GtkWidget. But maybe there is a technical reason for this.

Almost invariably you're going to be doing something with the return
value as a GtkWidget, such as calling gtk_widget_show() on it or packing
it into a container.  If that method above returned GtkMenuItem* then
that guarantees a cast, whereas if it returns a GtkWidget* then it may
just get packed into a container and that's the end of it.

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Danielle Madeley]

On Tue, 2009-11-03 at 23:47 -0600, Cody Russell wrote:

> On Wed, 2009-11-04 at 06:23 +0100, Javier Jardón wrote:
> > The question: why is it normal for GTK widget "constructors" to return
> > GtkWidget and not their real type?
> >
> > For instance I would expect:
> >
> >    gtk_menu_item_new ()
> >
> > To return GtkMenuItem*. But it doesn't, it returns GtkWidget*.
> > IMHO is much clear that constructors return their real type, instead
> > GtkWidget. But maybe there is a technical reason for this.
>
> Almost invariably you're going to be doing something with the return
> value as a GtkWidget, such as calling gtk_widget_show() on it or packing
> it into a container.  If that method above returned GtkMenuItem* then
> that guarantees a cast, whereas if it returns a GtkWidget* then it may
> just get packed into a container and that's the end of it.

What Cody is trying to say is that the pointer type returned is a
convention for convenience, since C doesn't have the idea of type
inheritance.

If you were to call G_OBJECT_TYPE() it would return GTK_TYPE_MENU_ITEM.

--
Danielle Madeley

Collabora Ltd., Melbourne, Australia
http://www.collabora.co.uk/

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Sven Herzberg]

Hi,

Am Mittwoch, den 04.11.2009, 06:23 +0100 schrieb Javier Jardón:
> The question: why is it normal for GTK widget "constructors" to return
> GtkWidget and not their real type?

Cody perfectly replied to that already.

> PD: If there is not technical reasons, maybe we can change this for
> GTK+ 3 (or 4 ;)), as I think a change like this will break the 2.x
> ABI.

This change wouldn't break ABI (unless applications use). But it is a
serious API impact (just think of all the warnings about "wrong" types
in assignments.

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).

Regards,
  Sven

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Andrew Paprocki]

2009/11/4 Sven Herzberg <herzi@...>:
> 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)

-Andrew
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Tristan Van Berkom]

On Wed, Nov 4, 2009 at 4:11 PM, Andrew Paprocki <andrew@...> wrote:

> 2009/11/4 Sven Herzberg <herzi@...>:
>> 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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Colin Walters]

On Wed, Nov 4, 2009 at 6:33 PM, Tristan Van Berkom <tvb@...> wrote:
>
> 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 ?

Introspection currently assumes any function matching foo_bar_new.* is
a constructor; i.e. in the .gir, the return type is the derived class.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list