Re: should destroying set the refcount to 0?
- From: Darin Adler <darin eazel com>
- To: Owen Taylor <otaylor redhat com>, Gnome Components <gnome-components-list gnome org>, Maciej Stachowiak <mjs eazel com>
- Subject: Re: should destroying set the refcount to 0?
- Date: Wed, 29 Mar 2000 08:57:05 -0800
on 3/29/00 8:16 AM, Owen Taylor at otaylor@redhat.com wrote:
> Almost certainly not. If you have refcounting on an object
> then you can't also have explicit destruction.
>
> For example: gtk_object_destroy() does not directly affect
> the refcount at all. The only reason it usually results in
> a widget being freed is that it remove the widget from its
> parent, so the refcount drops to zero.
>
> Either you have to have no _destroy() and just use unref(),
> or you have to make _destroy() a "break known references"
> operation.
My thinking on this is that there's no reason to have bonobo_object_destroy.
I think the people get confused by the example of Gtk, where there's both
ref counting and destroy and think that the two can coexist. But this is
only appropriate if you create the notion of a destroyed but "still around"
object like we have in Gtk with destroy and finalize.
Federico had to remove _destroy from GnomeVFSURI for a similar reason; it
was in there but didn't really make sense.
I suggest we remove bonobo_object_destroy. But this requires modifying and
checking over a lot of code. There are 26 calls to the function inside the
bonobo module itself. They can all be changed to bonobo_object_unref, but
there may be some cases where more than one _unref is actually needed.
In the mean time, it's still a good idea to have bonobo_object_destroy set
the ref count to 0 and I'll add that to my patch. With that change, further
calls to ref and unref will return_if_fail, so they'll be harmless and give
out CRITICALs. Of course, actually using the object will still be a problem.
We could add return_if_fail based on the ref count to more of the Bonobo
object routines too if desired.
-- Darin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]