Re: GObject and Gtk+ Finalization

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes: 
> As far as I can tell, a non-sunk object acts the same as long as you never
> call _sink on it.  That is, if the user code doesn't call sink you aren't
> changing semantics on the conversion.  An unref of an object with a floating
> refcount still seems to unref the object correctly.  The fact that the object
> is sunk or not doesn't seem to enter into it.
>

The following is OK with a floating object:
  Object *o = object_new ();
  pass_object_to_owner (o); /* does ref/sink */

with a nonfloating object, you have to do this:
  Object *o = object_new ();
  pass_object_to_owner (o); /* does ref */
  object_unref (o);
 
If this isn't what your code looks like, then your code was broken,
either the user code or the library.
 
> I would say that this is a hack though (setting data with a destroy
> notifier).  This is a common enough thing that there should be a more
> "nonhackish" way to do it.
>

We could add a simple wrapper around doing this similar to
gtk_object_weakref().
 
One disadvantage is that this destroy notify is called after the
object is mostly finalized (except for the GObject base class part). 
So notification of shutdown is likely more interesting than
notification of finalize.

> I'm not actually sure that the whole "object can be used after destroyed"
> isn't a bit bogus.  I'm sure gnome-libs objects mostly fail here.  But that's
> a different argument.
> 

This rule is required, or holding a refcount is not useful. Objects
must be safe to touch as long as you have a reference. In practice yes
only certain operations have to be safe (unref, checking whether it's
destroyed, get/set object data, etc.) so that's why we get away with
broken objects.

> I think that a destroy signal is generic enough and usable enough on non-GUI
> objects that it should be in GObject actually.  A destroy type functionality
> is useful in other objects as well I think.  Any system where you have many
> objects structured in trees holding references to each other, you will need
> something akin to the destroy signal.
> 

I'd be interested in Tim's full rationale for leaving it out.

Havoc