Re: GObject and Gtk+ Finalization

[Owen Taylor <otaylor redhat com>]

George <jirka 5z com> writes:

> > 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 wouldn't consider it very hackish. Note that a destroy notifier
without data can't be bound to an interpreted language, since the
"callback" for an interpreted language is typically stored as
data.

We do have:

void gtk_object_weakref	  (GtkObject	    *object,
			   GtkDestroyNotify  notify,
			   gpointer	     data);
void gtk_object_weakunref (GtkObject	    *object,
			   GtkDestroyNotify  notify,
			   gpointer	     data);

In GtkObject which is a trivial wrapper around object data; and
we could move that to GObject. But I would consider that to
be minimally useful.
 
> 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.

They'll need to be fixed for GTK+-2.0; it's not hard, we've done
it for most or all of the objects in GTK+ already.

The reason for changing the meaning of ::destroy from notification of:

 - Object is going into the destroyed state

to a command:

 - Release all references to the object

Is that this "destroyed state" was confusing and almost everything
was broken with respect to it. Most objects were put into an
inconsistant state on ::destroy and attempts to use a destroyed
object would probably result in segfaults.

The new model is simpler, easier to understand, and easier for
those people implementing widgets to get absolutely right. 

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

No real opinion here. 

I think the general point would be that if you don't have a concept of
a tree, and you frequently don't for non-GUI objects, then
having to implement ::destroy semantics is just unecessary
bloat.

Regards,
                                        Owen