Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Dave Benson <daveb idealab com>]

On Thu, Dec 15, 2005 at 12:33:52AM -0600, Yevgen Muntyan wrote:
> ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
> 
> >When you are calling your own code, it is not that 
> >much to keep track of, but when I write code that is used by 1000 
> >developers it is much easier for me to take care of the reference issues 
> >inside the API and make the large group of unknown developers free from 
> >unknowingly creating reference counting bugs.
> > 
> >
> So, the thousands of another developers now will have to check
> documentation for any GObject-derived class to figure out whether
> they own reference or not. This is exactly why it's good when you
> invent your wrappers, where it's clear that wrapper is made for
> purpose and one might be interested in what that wrapper does.
> So, if before the usage pattern was:
> 
> object = create_object ();
> ...
> g_object_unref (object); /* I do know I own it */
> 
> now it will be
> 
> object = create_object ();
> g_object_ref_sink (object); /* who knows what will happen in ... */
> ...
> g_object_unref (object);
> 
> Is it really good for glib, the library which is used by all people 
> using glib,
> not just those 1000 unknown developers who are not aware of the need
> to free allocated memory?
> 
> These arguments about bugs and stuff are good arguments about why
> one should use C++ or whatever other language with some sort of automatic
> memory management. C is known not to be safe, and it's known that you
> must be careful. After introducing floating references one will still need
> to be as careful, but he also will need to check one more thing - floating
> reference (or sink it as soon as possible).
> Maybe real solution would be for those 1000 guys to use mono or something?
> 
> In short, it's nice that glib will be more safe for those who do not check
> what his code does, but if one tries to write safe code, he'll get one more
> headache.
> 
> Regards,
> Yevgen

agreed!  the only really solid arguments i've heard
for this change are from the people who want a reliable
way to get a non-floating refernce (typically for bindings).
i've felt that problem myself in writing xml<->object mappings...

i personally would prefer a more conceptually-compatible api
change, for example, a GObjectClass method to convert
a potentially floating reference into a real reference (ala ref_sink),
where the floating flag's implementation is deferred to a derived class.

people who want floating flags could always derive from GtkObject if they
don't want to reimplement it...

- dave