Dave, Using the same container example which needs to take ownership of GObjects passed to the public API -- The problem we have is that much more time and effort goes into crafting the core container objects, and having inconsistent public API (two methods) to add an object to a container is highly undesirable. This leads to confusion and bugs in our experience. The burden should be placed on the person designing the container to ensure that the public API calls properly ref/sink when needed thereby eliminating the burden from the much larger group of programmers which will be calling the API.
We have run into consistent problems when writing reusable objects for an audience of over a thousand developers at our firm. Since callers of the API are not expected to be fully literate in GObject semantics, pushing the burden to the caller (requiring them to unref after passing) can lead to nasty memory leaks. Similarly, creating two API calls to pass an object into a container is also not desired because it leads to confusion when the callers are not familiar with GObject's ref-counting implementation. Remember, this problem occurs because the implementor chooses to use GObject to simplify their own task by having a proper object-oriented approach in the C. If going down this path exposes GObject to the target audience, then GObject is lacking what is needed to sufficiently hide the implementation details. This is not to say that it isn't possible for everyone desiring this implementation transparency to create their own derived class with the floating ref/sink behavior. I think that if others have this goal then it might be time to include the behavior in the base package so no one needs to implement it themselves. Andrew Bloomberg LP > To: Tim Janik <[EMAIL PROTECTED]> > From: Dave Benson <[EMAIL PROTECTED]> > Subject: Re: GObject reference counting / lack of "sink" issue > Date: Sat, 1 Oct 2005 08:40:56 -0700 > > On Fri, Sep 30, 2005 at 01:38:40AM +0200, Tim Janik wrote: > > you are right, GObject is widely used these days out of GtkObject contexts, > > and anywhere in C land (where memory book keeping or reference house keeping > > can't be automized) when objects are created and ownership is passed on, > > a floating flag is strongly desired (and forces you to derive and > > reimplement > > if you're consequent enough ;) > > > while i think that the floating flag is a good idea, > i'm pretty skeptical about its addition at this point... > in particular, such an addition doesn't modify > the api per se, but certainly modifies "best practice". > > for example, users will have to choose whether certain > methods sink or not, and it won't be possible to modify > existing api to be consistent. > > to take an example: g_value_set_object(). > once you add a floating flag, it'd be tempting > to assume that you can safely: > g_value_set_object(value, g_object_new(...)); > but changing set_object to sink would break api. > > and, in my opinion, there already has been invented > a nice enough solution to this problem: > g_value_take_object(value, g_object_new(...)) > > if you are implementing a container class simply have > my_container_take_object(container, child); > and > #define my_container_add_object(container,child) \ > my_container_take_object(container,g_object_ref(child)) > > which will actually be more efficient > than a bunch of bit-twiddling, and probably easier to understand. > > - dave > > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
