Re: Sinkability considered harmful

On Wed, 2006-01-04 at 00:15 +0000, Gustavo J. A. M. Carneiro wrote:
> On Tue, 2006-01-03 at 18:52 -0500, Owen Taylor wrote:
> > On Tue, 2006-01-03 at 23:43 +0000, Gustavo J. A. M. Carneiro wrote:
> > >   Completely agree.  Interesting read too.   I'd just like to add one
> > > more thing.
> > > 
> > >   g_object_new *should* always return a new reference, to be owned by
> > > the caller.  It usually does, except for g_object_new(GTK_TYPE_WINDOW,
> > > NULL), in which case the caller does not own the object ref.  I don't
> > > quite understand how this happened.  It should not be due to backward
> > > compatibility because this is a new API (in glib 2.0). 
> > 
> > See my last mail explaining why g_object_new(GTK_TYPE_WINDOW) is just
> > like g_object_new(GTK_TYPE_ENTRY). You don't own the initial reference
> > in either case.
> > 
>   In your last email you don't say anything about GTK_TYPE_ENTRY, as far
> as I can see. 

Just an example of the behavior that occurs for EVERY TYPE OF WIDGET.

>  And the explanation  "GtkWindow's are created owning
> their own refcount, which they unref on ::destroy"  does not justify
> anything, it merely states a fact.  I can almost understand why, in C,
> gtk_window_new() can return a borrowed reference.  But g_object_new() is
> a rather different API; it is mostly oriented towards language bindings
> (or at least that's what it looks to me) and so it should be clean of
> the inconsitencies that plague the gtk_*_new functions.
>   And are you sure g_object_new(GTK_TYPE_ENTRY) returns a borrowed
> reference?  If so, you may have uncovered a PyGTK bug, and would just
> emphasizes how bad this inconsistency is.

Whenever you create a descendant of GtkObject with g_object_new(), you
get an object with an ephemeral reference count.

 - For most GtkObjects, the reference is owned by *nobody* (definitely
   not by you)
 - For GtkWindow descendants, the reference is owned by GTK+ and will
   be released on destroy().

In either case, the sequence


Gives you a refcount that you own. This is mandatory if you are going
to hold onto a pointer to the object and I'm pretty positive that
PyGTK in fact does this.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]