Re: Proposal: Ref Counting Conventions (CLOSED)

[Mike Fleming <mfleming eazel com>]

Ok, it looks like we've reached a conclusion (and no one has posted
further arguments in the last few days) so I just wanted to close this
issue out by restating what we've decided.  I'll also go bug doc authors
to make sure this gets included.  I'm not sure that I personally have
time to go and audit implementations :), but I hope that people change
their implementations to follow this convention relatively soon.

The Bonobo ref count convention is as follows.  (Mild rewording; same
meaning as before)

1. A function returning an object, either as the return value or
by-reference, must always add a reference before returning. 
(Alternately: the callee must create a reference to the returned object
that the caller owns)

2. A function that accepts a bonobo object as an in/out parameter must
unreference the originally passed object once if the function wishes to
change the value of the in/out parameter.  (The function must ref() new
objects returned via this in/out in accordance with [1])

3. An object passed into a function needs only be ref()'d if the
function wishes to retain a reference to the object beyond the scope of
the function call.

In addition, there's a consensus that interface designers should be
advised against designing methods with in/out parameters.  In/out
parameters can obscure the lifetime of the passed argument to casual
code observers, and thus may cause hidden side-effects.

Thanks all!

Mike Fleming

Miguel de Icaza wrote:
> 
> > This is a long post with fragments of the argument clipped together.  Here
> > is a summary of my position:
> >
> > 1. It seems that people agree about conventions (1) and (3).  Should we
> > adopt them?
> >
> > 2. Convention (2) deals with inout parameters.  I maintain that convention
> > (2) correctly distinguishes inout's from "in's" and "out's" and that it
> > allows callers to have consistent behaviour and not have to do anything
> > weird when dealing with such parameters.  My argument continues below
> >
> > 3. I'd also agree that "inout" parameters are confusing and often
> > unnecessary.  Usage of "inout" parameters should be avoided if reasonable.
> > However, since "inout" exists in CORBA, we should have a convention for
> > dealing with it.  Actually, the fact that it is rarely used makes my
> > visual auditing argument below even more poignent.
> >
> > 4. As far as I know, nobody has a silver bullet for tracking down refcount
> > issues.  I certainly never saw one in the COM world.  The best defense
> > against refcount bugs is clear, consistent rules so that source code can
> > be visually audited to see if it follows those rules.
> 
> I agree on all counts.  The inout problem turned out to be a rather
> nasty nest.
> 
> Basically, lets just discourage people from using "inout" on
> Bonobo::Unknown objects.
> 
> Miguel.
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list