Re: Weak references for GObject

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

Hmmm, I have a feeling that the fact we need to do this is a symptom
of misdesign somewhere. I think the misdesign may be simply
that we allow arbitrary people to call gtk_widget_destroy() ...
we basically have an "ownership" pattern, where widgets
are owned by their parents, so allowing external parties
to destroy is a bit fishy....

Anyways, that certainly can't change, and yes, we do get a fair bit
extra level of safety by doing setup before the destroy virtual
functions are called .. I will admit that.

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

I believe g_object_dispose() is fine ... it certainly should
not be caled g_object_dispose_internal, since it isn't an
internal function.

We could call it something like g_object_run_dispose()
if you want to make clear (beyond documentation) that it isn't 
a way to destroy something, but just a step within
the process.
> 
> >  - 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.

Terms like "public" are vague - I mean, only, something that can
be called from outside of GObject.

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

Well, there is such a thing as providing too much flexibility, and
GObject probably crossed that line many miles ago. 

However, the point about needing to get in to clean up before
->destroy() is run is fairly convincing that we need to maintain a
->destroy() as the method of choice for GtkObjects.

Given that, I guess the changes in rough outline come down to:

 - Rename shutdown() to dispose()
 - Notify weak references out of dispose()
 - Provide a public entry point to run dispose() at a time other
   than finalization time.

Which seems quite reasonable. Its fine with me if we do it this
way.

Regards,
                                        Owen