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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
