Re: Abstract string properties with getter/setter functions

[Tim Janik <timj gtk org>]

On Thu, 20 Sep 2007, Raffaele Sandrini wrote:

> On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote:

> > erm, no. that's at least not a clean solution, ref counts may increase and
> > decrease at any point in time for random reasons (caches, garbage collection
> > algorithms, etc...), even from concurrently running threads without holding
> > the GDK lock.
> >
> > > Take a look at the GtkFileChooser interface
> > > there this hack is used several times. (and annotated as such)
> >
> > hm, not here:
> > $ fgrep ref_count gtk/gtkfilechooser*.c
> > $
>
> 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);

this code is not peeking at preview_widget->ref_count, it
just always unrefs because by getting it always owns a returned reference.

>  return preview_widget;
> }
>
> > > All we need from you is either a solution or the statement that this is
> > > not possible with gobject properties ;).
> >
> > i don't quite get what you're trying to achive.
> > but if efficiency is your only concern, i do think that you
> > can spare a string copy by using g_object_get_property()
> > instead of g_object_get(). it just still will be internally
> > copied when it's passed around as a GValue (g_object_get
> > just does two copies alltogether, the second of which needs
> > to be freed by tha caller).
>
> That might be true but does not help here.

well, you still fail to say *why* this does not help
or poses a problem for you.

> We use getters/setters all
> through Vala for several reasons including the ability to embed a
> getter/setter in any kind of C expression and due to speed concerns with
> GValue. The memory convention of getters/setters is to return "weak"
> references.

this is *not* a convention of getters in glib/gtk programs.
like i said in my first email, some getters return peeked contents,
some return duped/referenced contents.
technically, it is *not* possible to implement all getters as peeking
functions because return values may be constructed on the fly.
so any convention that demanded only peeking getters would be in error
because it'd be technically impossible to implement thoroughly.

(maybe what you're saying is that this is a convention for vala
getters... but then, that's something you'd very badly have to fix,
because it is *not* implementable for all C programs, even beyond
glib/gtk programs.)

> cheers,
> Raffaele

---
ciaoTJ