Re: GObjectClass.dispose and bringing objects back to life
- From: Emmanuele Bassi <ebassi gmail com>
- To: Benjamin Otte <otte gnome org>
- Cc: gtk-devel-list gnome org
- Subject: Re: GObjectClass.dispose and bringing objects back to life
- Date: Sun, 4 Dec 2011 13:40:58 +0000
On 4 December 2011 13:23, Benjamin Otte <otte gnome org> wrote:
> 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
> 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.
this is, of course, not true: GNOME is full of badly written GObject
code, mostly because it has been written at various stages of the
learning process of various people. plus, the documentation is not
entirely clear in a lot of places, thus the learning process can (and
effectively is) broken.
> 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
objects should obviously not be in a fully functional state after
dispose - but they should be in a stable state, so that other objects
referencing them from outside of the boundaries of their code space
can still hold a valid reference to them, until such time that every
reference can be released.
> What we probably also should do is deprecate one of the two
> virtual functions, so people use the same one to clean up everywhere.
this would be insane and wrong on so many levels that it's not even
funny to contemplate them.
the double-step in the object lifecycle end is necessary in a
refcounted system with reference cycles. you cannot just release
references to an object on finalize() if there is even the slightest
chance of a cycle; any attempt at doing so introduces instabilities,
segfaults, or leaks.
] [Thread Prev