Re: GTK_FLOATING broken in 2.9?

[Dave Benson <daveb idealab com>]

On Thu, Dec 15, 2005 at 05:07:34PM +0100, Tim Janik wrote:
> On Thu, 15 Dec 2005, Dave Benson wrote:
[long discussion cut]
> >this thread never really addressed my concern,
> >which was that this makes it so that container classes
> >before 2.10 have one style, and >=2.10 have another.
> >considering that this change is trying to simplify
> >memory management, i'm dubious.
> >
> >as i origianlly mentioned, my example is
> > g_value_set_object()
> >which clearly should ref_sink(), but clearly cannot
> >for abi compatiblity reasons (though i'm not exactly going to
> >be shocked when a patch goes in that does it anyways...)
> 
> you're right that simply changing that function take over one
> reference for floating objects would break existing user code.
> 
> compatibly, you can add extra value setters that properly sink
> though, if you think adding that API is worthwhile.
> 
> and you could then deprecate the old API if you think that'd be wise.
> 
> (i'm intentionally leaving this open)

so... do you agree that if you could, g_value_set_object()
would ref-sink?  

if so, then isn't it confusing that it doesn't?
you shouldn't really have to read the api docs for
every function to know their memory-management policy...
that's the whole point of the "never pass ownership 
through function-calls paradigm" (which, i think is it driving force
behind needing sink at all-- if you just admit g_value_take_object(),
then sink becomes somewhat superfluous.)

which is why i thought GObject didn't have a floating flag to
start with... b/c it's only good for a certain few usage patterns.
in particular, with widgets, there's a natural parent which will
sink the object.  in more general cases, it's unclear who sinks the object.
(i recall a debate whether gtk_container_foreach() sunk...
that's just due to the fact that there's no precisely defined
sematics for who sinks)

anyways, *nothing* can fix:
  object = g_object_new (MY_TYPE_OBJECT, NULL);
  g_object_ref_sink (object);
  my_object_ref_sink (object);
  g_object_unref(object);
  g_object_unref(object);
except upgrading the 'my_object' library to a version that 
depends on a late glib.. but if people are just upgrading glib
to say, move to a later gtk, then well, they won't notice the
situation.

- dave