Re: recent Bonobo destroy/unref fix

[Darin Adler <darin eazel com>]

on 7/11/00 3:34 PM, Michael Meeks at michael@helixcode.com wrote:

> The 'bonobo_object_ref' then 'gtk_object_unref' one =) makes for
> interesting back traces, much use of 'watch' and banging of head against
> desk both of which need dents removing.

You could make that way easier to debug by adding code to
bonobo_object_finalize_real that checks some flag that is only set by
bonobo_object_finalize. But of course only if you can find a way to do that
without unnecessary BonoboObject bloat I guess. I'd really like to catch
people doing gtk_object_destroy or gtk_object_unref on a BonoboObject. I'd
like to catch people doing gtk_object_ref too, but that seems almost
impossible.

>> It's customary to call through to the parent class in the implementation of
>> a child class's "destroy" function, so after removing the call to
>> bonobo_object_destroy in bonbobo_property_bag_destroy I believe you should
>> have added a call to the parent class's destroy function. This call to
>> parent class may be missing from other functions in bonobo as well, but it
>> could be harmless in practice. Perhaps it's intentional?
> 
> Indeed; not deliberate, an ommision on my part; I forget what the
> original did, but I have no doubt that it was quite grim. It is not only
> customary but mandatory to chain destructors, unless you are doing
> something extremely stupid or clever =)

In my last project I had a system that checked in debug builds to make sure
you didn't forget to chain through. The caller (code inside GtkObject in
this case) would set a bit (OK, I admit it, it was a hash table entry), the
ultimate ancestor you were supposed to call through to (gtk_object's destroy
default handler in this case) would check and clear the bit, and finally the
caller then check it was clear. You got an easy to debug error if you forgot
to call through or if anyone called the underlying handler directly by
"accident".

    -- Darin