Re: Weak references for GObject

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 11 Jun 2001, Owen Taylor wrote:
> 
> > I discussed this issue for a long while wth Tim this morning; 
> > our concluding scheme was somewhat different than my original
> > proposal. 
> 
> > Tim's main concern was that people would want to create object
> > types like GtkObject, with explicit destruction; every such
> > object type would have:
> > 
> >  * Its own gtk_object_destroy() public function for destruction
> >  * Its own virtual function equivalent to ->destroy() in GtkObject
> > 
> > This causes code duplication of tricky code portions and causes
> > a lack of unity across GObject using code.

Note this rational here -- I don't think we should reintroduce some of
the more questionable items from GtkObject into GObject for no good
reason. You convinced me earlier, that there was enough simplification
in unifying destructable-object handling across different types of
GObject, that it was worth giving GObject essentially the GtkObject
model of destructution.

If you've changed your mind and _don't_ think that having a consistent
public function and virtual function makes sense, then I don't see the
benefit of changing around GObject, and we should simply go with my
first scheme - add weak references and an "protected" function to
notify weak references prematurely.

(See my mail of 6 June)

[....]

> ok, now onto the main reason why simply "replacing" destroy by dispose
> is not such a good idea. the very reason to introduce shutdown in the
> first place was, in GTK+ core we need to do certain things when we're
> about to emit ::destroy, but haven't started yet. the prime (though not
> sole) example of this is gtk_widget_shutdown() removing children from
> parents and (thus) unrealizing the widget.
> for non-core-developers:
>   if we didn't (via shutdown) make sure a child is removed from its parent
>   before ::destroy gets emitted, widget destruction in classes derived from
>   GtkWidget couldn't make all kinds of assumptions like widget->window and
>   other resources associated with realization being gone. furthermore, since
>   gtk_widget_shutdown() not only removes children from their parents,
>   but also unrealizes toplevel widgets, X window destruction would
>   occour from leafs up the tree, a very slow and inefficient process.
> 
> as a result out of the remaining need for a "hook" before GtkWidget-derived
> type destructors are called, and the above mentioned hints towards not making
> g_object_dispose() publically callable, we should change things towards:
> 
> - not making the recommendation that people use ->dispose instead of ->destroy.
>   instead, for the scope of Gtk+, leave things for implementors as they are,
>   i.e. they shouldn't worry about dispose in their code.
> - call the dispose invocation function g_object_dispose_internal(). only
>   library implementations should use it, e.g. for Gtk+ that'd be
>   gtk_object_destroy(), for BSE, that'd be nowhere (still gets triggered
>   upon last_unref situation), and for bonobo, where i heared explicit
>   destruction is required, that'd be something like bonobo_object_destroy()
>   i guess.

I'm very much still asleep at the moment, so bear with me...

Could you explain:

 - What changes you are planning to do. (Rename shutdown to dispose
   and then automatically notify weak references in GObject::dispose?)

 - Why they are better than simply adding a public funnction to
   prematurely notify weak references; (that seems to gives objects
   which want to control their own destruction maximum flexibility)

Regards,
                                        Owen