Re: GObject and Gtk+ Finalization

[George <jirka 5z com>]

On Sun, Sep 24, 2000 at 11:54:56AM -0400, Owen Taylor wrote:
> > I'm not actually sure that the whole "object can be used after destroyed"
> > isn't a bit bogus.  I'm sure gnome-libs objects mostly fail here.  But that's
> > a different argument.
> 
> They'll need to be fixed for GTK+-2.0; it's not hard, we've done
> it for most or all of the objects in GTK+ already.
> 
> The reason for changing the meaning of ::destroy from notification of:
> 
>  - Object is going into the destroyed state
> 
> to a command:
> 
>  - Release all references to the object
> 
> Is that this "destroyed state" was confusing and almost everything
> was broken with respect to it. Most objects were put into an
> inconsistant state on ::destroy and attempts to use a destroyed
> object would probably result in segfaults.
> 
> The new model is simpler, easier to understand, and easier for
> those people implementing widgets to get absolutely right. 

Well regardless of that, how can I release all references to a GObject if I
never get a destroy signal?

1) By the finalize time things will really be broken, so I can't be sure that
   the object is even half working
2) You can get circular references

Not to mention that "release all references" at many times is half destroying
the object really, as the object may depend on holding some references.

> No real opinion here. 
> 
> I think the general point would be that if you don't have a concept of
> a tree, and you frequently don't for non-GUI objects, then
> having to implement ::destroy semantics is just unecessary
> bloat.

However if you do, (and I think it's not that uncommon actually for
structured data), having to implement your own such beast doesn't really seem
too nice, meaning there will be no standard way to hook into this for such
objects.

George

-- 
George <jirka 5z com>
   She had lost the art of conversation, 
   but not, unfortunately, the power of speech.
                       -- George Bernard Shaw