Re: GObjectClass.dispose and bringing objects back to life

[Morten Welinder <mortenw gnome org>]

> What we probably also should do is deprecate one of the two
> virtual functions, so people use the same one to clean up everywhere.

That would be a _really_ bad idea.

_finalize gets rid of the last fragments of the object.  Since random
code could have obtained refs to the object, the object designer
can generally not control when this happens.

_dispose has two functions: (1) break reference cycles by getting
rid of as many objects as it can, and (2) getting rid of externally-
visible parts of the object and subobjects it owns.

(2) tells you why you can't merge the two methods.  Widgets,
for example, really need to go away from the screen when you
tell them, not whenever something else decides to release a ref.
Objects that have open files really need to close them at dispose
time, not next Wednesday.

Gtk1 didn't have dispose in name, but it had the destroy method
instead.  Same thing.

> [...] we [...] know that trying to support objects functioning
> after dispose is like trying to make your code handle
> NULL returns

I don't think we know that, not do I think it's true.

Making _dispose work really comes down to following one
simple rule: after _dispose, the object should be as well defined
as it was after _init.  I.e., anything you free you set to NULL
and you don't free anything that was allocated in _init[*].

M.


[*] Unless you allocate a new dummy object to put in its place.
That wouldn't make much sense unless you have big trouble
with circular references.