Re: GObjectClass.dispose and bringing objects back to life

[Benjamin Otte <otte gnome org>]

Tristan Van Berkom <tvb <at> gnome.org> writes:

> Yes, real-world well-written GObjects *must* not crash after being disposed,
> code that crashes because apis are called after dispose time are bugs,
> and you should fix them as specially if you have possible circular object
> references.
> 
This is of course not true.

Because if it were true, the whole GNOME stack would not be real-world
well-written GObject code and I think we all agree that a lot of our code is
pretty damn good.

So why does GObject even have dispose? Why does it ship this obviously wrong
documentation? And why do some people believe that objects must survive after a
dispose?

This all goes back to the days when glib developers were inexperienced and were
just coming up with a way to make GObject usable from garbage-collected
languages. Many ways were invented to make this work, some more and some less
successful. You can see the leftovers of a bunch of them if you dive into
gobject.c and look at the code that is run when an object is destroyed.

These days of course we are smart and know that trying to support objects
functioning after dispose is like trying to make your code handle NULL returns
from malloc: It's virtually impossible to get right and makes your code both
larger and uglier. So people rightfully don't do it.

What nobody has done and what we probably should do is fix the documentation to
clarify this. What we probably also should do is deprecate one of the two
virtual functions, so people use the same one to clean up everywhere.

Benjamin