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

List:       gtk-devel
Subject:    Re: Sinkability considered harmful
From:       Tim Janik <timj () imendio ! com>
Date:       2006-01-04 14:33:54
Message-ID: Pine.LNX.4.61.0601041531040.1046 () localhost ! localdomain
[Download RAW message or body]

On Wed, 4 Jan 2006, muppet wrote:

> On Jan 4, 2006, at 6:33 AM, Tim Janik wrote:
>
>> On Tue, 3 Jan 2006, Federico Mena Quintero wrote:
>> 
>>> The "floating" flag was introduced in GtkObject to:
> ...
>>> 	2. make things easier for language bindings.
>> 
>> this is not quite right. the floating flag is of no use to langauge 
>> bindings,
>> if it affects them, it makes things harder for LBs.
>
> 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.

---
ciaoTJ
_______________________________________________
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]