[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Sinkability considered harmful
From:       Tristan Van Berkom <tvb () gnome ! org>
Date:       2006-01-04 14:55:57
Message-ID: 43BBF21B.60104 () gnome ! org
[Download RAW message or body]

Tim Janik wrote:
[...]
>> Actually (to throw a wrench in things), the floating flag *does* make 
>> language bindings easier.  The GtkObject wrapper can *always* do an 
>> unconditional ref and sink; if it was floating, e.g., returned from a 
>> constructor, the object is now owned by the wrapper, and if not, the 
>> wrapper is just another owner.  For non-floating objects, the binding 
>> author must now distinguish constructors from other functions in order 
>> to avoid leaking objects.  Gtk2-Perl has seen a lot of reference-count 
>> leaks related to GObject-returning functions that we marked 
>> incorrectly (human error), but none related to GtkObject-returning 
>> functions.
>>
>> That said, the main impetus for the human error involved in marking 
>> API functions has been the inconsistency of ownership for returned 
>> objects, that is, violation of the Principle of Least Surprise.  It's 
>> not cool to have to look at the reference docs for every single 
>> function to verify whether you need to unref the return value.
> 
> 
> ok, thanks for the insight. sounds like LBs will also benefit from sinkable
> GObjects in the long run then.
> 

muppet,
     GtkObject is a special case, it means that in your
binding you have to distinguish it from a GObject and treat
it differently, if there were no floating flag; you wouln't
need to do this.

If OTOH, you call a function like:
    my_foo_get_internal_bar()

you cant count on the returned "bar" to be owned by you,
maybe it would be nice if functions returning internal
objects were to return "const" to clarify that.

either way; the fact that some functions dont return
a reference and some do is irrelevent to floating
objects, if it can happen with a GObject; it can happen
with a GtkObject.

Cheers,
                        -Tristan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]