Re: Sinkability considered harmful

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

Qua, 2006-01-04 às 15:33 +0100, Tim Janik escreveu:
> 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.

  In the long run it will not make any difference either way since we
will be using "full" introspection metadata which includes ref ownership
information explicitly; or at least should include it...

  Regards.
 
-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.