Re: ABI and API for g_object_ref_sink() (Re: GTK_FLOATING broken in 2.9?)

[Yevgen Muntyan <muntyan tamu edu>]

Tim Janik wrote:

> > Nobody so far said that objects with floating reference in glib is 
> > not needed.
> > But what about Murray idea, to create separate class; or, along same 
> > lines,
>
>
> that wouldn't change a thing. if you had a GFLoatableObject, you'd still
> want to derive GtkObject from it, so you may as well have it in GObject.

No, I would not want that because it would break GTK (as it does now).
This is why I like idea of separate class - those who need floating 
reference
in glib get it, and GTK is not broken and it's guaranteed that GTK won't be
broken after floating reference stuff gets into glib (good that Dave 
noticed
thing about new-glib + old-gtk, but what about other things that will be
noticed after new gtk and glib will get into distros?).
Only argument against separate class I can see is code duplication. But 
well,
what amount of code and how does it compare to GTK breakage?
Inconsistency and need to deal with gtk_object_sink and g_float_object_sink?
We have lot of such weird stuff, and nobody died so far.
And a separate class could be super-fancy class with super-clever reference
count mechanism, to nicely serve those who need it. Or it could be just 
broken,
without bad impact to GTK.

No, I do not think you are so bad that you write sucky floating reference
stuff in glib. Maybe this particular breakage is not that bad, and GObject
with floating reference is incredibly good for peace in the world. But it is
breakage, isn't it? Owen Taylor, Tim Janik, who's next?

You didn't say a single time "Yes, GTK and GLIB will remain source and 
binary
backwards compatible" (well, it wouldn't be true), and you did not describe
future GTK plans for backwards compability (except for stuff about 
gtk2.X and
glib 2.(x+2)).

Yevgen