Re: Abstract string properties with getter/setter functions

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"

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



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