Re: Proposal: Ref Counting Conventions

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel@helixcode.com> writes:

> > 1. A function returning an object, either as the return value or
> > by-reference, must always add a reference before returning.  (example:
> > query_interface apparently does this)
> 
> It definetly does.

Although there are many interfaces that don't. Bonobo::ViewFrame's
get_client_site method is one of many examples.

> > 2. If a function is passed an object as an in/out and wishes to return a
> > different object, the object that was passed in must be unref()'ed and
> > the new object ref()'d before returning
> 
> I do not like this.  At least the part in which I am supposed to unref
> something that was passed to me.  It breaks the convention that
> you ref when you want to keep  a reference to an object.
> 
> In this case, if you want to return another object, that is just fine,
> but you should not unref the one you got.  I believe this is a hack
> around the standard for "refing everything you return" that you
> propose above.

What would you propose as an alternate convention for inout
parameters? I think the idea here is supposed to be that you can treat
what you get back as functionally equivalent to what you passed in,
whether or not it actaully got replaced by a different object. This
actually even makes sense if you were holding multiple refs to the
original object.

Handling it any other way, you would have to test whether the object
you get back through an inout parameter is the same as the one you
passed in or not to know if you have to unref it.


> I am not entirely sure this will avoid the bugs.  I rather see well
> documented interfaces that describe the precise nature of the returned
> value and at the same time write some utility code in Bonobo that can
> keep track of reference counting for us, and can detect reference
> count leaks if possible.

Having and following conventions is still very useful even if you have
docs and ref leak detection code (although how to do the latter is a
mystery to me; it seems like a distributed GC problem). In fact, the
whole idea of having conventions is that you don't have to read docs
(or - more realistically - source, since many hackers do not write all
the doc they should) to figure out whether you need to ref a return
value you get, or whether it is OK to unref an object after passing it
to a function, and so on. You would just always know, because there is
a convention. 

For what it's worth, the conventions Mike described are the ones
typically used with COM. They were developed over the course of long
practical experience and work pretty well in most situations.

 - Maciej