Re: Abstract string properties with getter/setter functions

On 9/28/07, Federico Mena Quintero <federico ximian com> wrote:
> On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote:
> > Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
> > done there is somehow possible with objects it is not with strings.
> >
> > GtkWidget *
> > gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
> > {
> >   GtkWidget *preview_widget;
> >
> >   g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
> >
> >   g_object_get (chooser, "preview-widget", &preview_widget, NULL);
> >
> >   /* Horrid hack; g_object_get() refs returned objects but
> >    * that contradicts the memory management conventions
> >    * for accessors.
> >    */
> >   if (preview_widget)
> >     g_object_unref (preview_widget);
> >
> >   return preview_widget;
> > }
> By the way, this is a *TERRIBLE* idea.  I don't remember why I wrote the
> code that way.  Please don't follow that broken pattern.
> [In the file chooser it works because the GtkFileChooser implementation
> always holds a reference to the preview widget.]

I'm pretty sure that it's my code (or, at least, the first usage; it's
been cut-and-pasted a couple of times within that file). It's pretty
much forced by:

 - The way GtkFileChooser is set up internally using properties to
forward between the different implementations of GtkFileChooser -
Widget, Window, and the default implementation - without writing lots
of per-property manual chaining code.
 - The desire to have the public GtkFileChooser wrappers look like
most of GTK+  interface where a getter for a constituent widget
doesn't ref (think gtk_widget_get_child(), even)

And it is pretty safe considering the semantics of the particular
situation; if an application sets a preview widget, the file chooser
has to hold onto it, and return exactly that preview back out later.
But that's only by consideration of the particular situation. It isn't
generalizable across all object properties, and definitely not all
properties, and even more so not across all getters.

> It's much easier to write things if you always get a new reference from
> accessors.

It's the only universal pattern. It's not the convenient pattern for
using code from C, unfortunately. You see this a lot ... when you take
an automatically generated interface (COM, CORBA, etc), and use it
from C, you have a lot of tedious dereferencing. But there's no way
around that.

- Owen

[ And yes, I was completely horrified to to see anybody referring to
that code as an example to generalize ]

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]