Re: Weak references for GObject

[Tim Janik <timj gtk org>]

On 30 Jun 2001, Owen Taylor wrote:

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

that wasn't exactly how i meant things. afair, we started out with whether
there's a reason for _dispose to _not_ be a class function. and once
there, how that relates to shutdown since both need to be called prior
to finalization etc.
at some point (not sure how anymore though) we arrived at whether that
isn't simply moving ->destroy() into GObject while running ::destroy
only for notification purposes. in retrospect however, that's not such
a good idea as i outlined in my last email wrg gtk_widget_shutdown().

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

hm, i wonder whether you fully got my point about gtk_widget_shutdown()
(you being sleepy ;), if we just have ->dispose() in GObject and people
start to use that instead of ->destroy, Gtk has no way to slide in the
contents of gtk_widget_shutdown() _before_ widget destructors are being
run. i suppose the fact that we have to do this is not arguable, right?

> (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?)

code functionality wise, i'm still at the same level of the email you sent
out after our irc discussion. however, the recommendations are different,
i.e. people shouldn't use ->dispose but ->destroy for their destruction
functionality, and calling g_object_dispose() should be left to object
system implementations like gtk, bse, bonobo. as such i suggested calling
that function g_object_dipose_internal().

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

well, a _public_ weak_notify function is as much a shoot-yourself-in-the-foot
function as g_signal_handlers_destroy() is, or a g_object_delete_all_qdata()
function would be. so still, weak_notify would be something only callable
internally from client object systems.
however, when calling weak_notify object_dispose, and providing a class function
for it, i see several advatages:
- it's conceptually clearer to have a "dispose object" function that cares
  about weak-refs, signal handlers, and object-specifics all at once
- with ->dispose, client object systems can hook into this point to
  destroy object specifics (cross-links, agregate-links whatever) without
  using bad kludges such as setting a weak-ref for solely this purpose upon
  every object_init function.
- client object systems that do allow for explicit destruction, such as
  the Gtk+ one, don't need to use bad hacks like calling ->shutdown()
  directly but have a definite API entry point for solely this purpose.
- reserving object_dispose[_internal] for client object system implementations
  makes sure it's only called for object systems that actually _do_ allow for
  explicit destruction.


> 
> Regards,
>                                         Owen
> 

---
ciaoTJ