Re: GObject and Gtk+ Finalization

[George <jirka 5z com>]

On Sun, Sep 24, 2000 at 01:22:42AM -0400, Havoc Pennington wrote:
> Well you aren't doing it wrong for 1.2, just wrong if you want to
> convert things to GObject, which isn't actually _necessary_ just handy
> to strip the GTK library dependency when/if you want to do that.
> Typically this isn't even possible for released APIs because of the
> floating refcount issue, all user code suddenly leaks memory if you
> convert to GObject... but GtkObject stuff that's not yet released can
> be hacked to ref/sink in the constructor and thus avoid changing
> semantics on GObject conversion.

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 simplest way is to set object data with a destroy notifier. (Note
> that "destroy notifier" here means it's called on finalize, as it is
> in GtkObject now. Be careful because unlike with a callback connected
> to the "destroy" method, with a finalize notifier it's pretty trivial
> to create a cyclic refcount. "destroy" is more or less a solution to
> the cyclic refcount problem, which GObject does not provide for you
> since it's perhaps not a generic or typically appropriate solution for
> non-GUI objects. Well, "destroy" is also in part a historical artifact
> of the fact that widgets weren't always refcounted.)

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.

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.

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.

George

-- 
George <jirka 5z com>
   If you think nobody cares if you're alive,
   try missing a couple of car payments.
                       -- Earl Wilson