recent Bonobo destroy/unref fix

[Darin Adler <darin eazel com>]

I noticed in your recent change to Bonobo that you left behind a
bonobo_object_destroy function. The warning statement in the source makes me
think that you left it for use by Nautilus until we are sure that the
control/control-frame mutual reference problem is resolved.

However, Nautilus does not yet compile because this function is no longer in
a header. Did you expect that we would add a prototype for the function to
Nautilus as a temporary hack?

I noticed that you also made changes to BonoboControl and BonoboControlFrame
Do you think you have resolved the control/control-frame mutual reference
problem? Should we be giving it a try (using bonobo_object_unref and getting
rid of our call to bonobo_object_destroy)? This would be the best outcome.
If it's not already fixed, are you planning on fixing the
control/control-frame mutual reference problem, or should I try to fix it?

If the mutual reference problem still isn't resolved then I guess we are
forced to continue using bonobo_object_destroy in Nautilus to work around
the circular reference so we don't leak CORBA objects and server processes
like we did in the past. Should we be calling both bonobo_object_destroy and
bonobo_object_unref after your change, because you have given destroy a
semantic like the one for gtk_object_destroy?

--------

Other comments on your changes:

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?

    -- Darin