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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list