Re: GObject reference counting / lack of "sink" issue

[Dave Benson <daveb idealab com>]

On Mon, Oct 03, 2005 at 02:09:27AM -0000, Andrew Paprocki wrote:
> 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.

you cannot avoid it in c:
you must understand the ref-counting policy.  

if you wish for thousands of developers to never have a
a problem, you should switch languages.

- dave