Re: Proposal: Ref Counting Conventions

[Miguel de Icaza <miguel helixcode com>]

> > > 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.

Thanks for pointing this out.  Can you file a bug report for Bonobo in
this case, or better yet, submit a bug report?

> 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.

Proposal:

	inout parameters should be treated just like an in parameter
	and an out parameter.

	This means: no special unrefing of the object you get passed
	to.

Reply to the original proposal and sort of rationale:

An out parameter just happens to be an extra return value that
syntactically does not look as cute as:

	x = fn ();

It is just:

	fn (&x);

The problem is that you pass some data *in* and then get some data
*out*.  inout is just an implementation trick to provide the illusion
of "efficiency", because "void x (inout Object a)" is nothing more
than: "void fn (in Object a, out Object b)", or to use the example above: 
"Object fn (in Object a)".  

Unrefing your first argument in this case is obviously broken[1],
because then every invocation to a method should become (for simetry): 

	x_ref (a);
	x_op (a, &ev);

Every single one of them.  Because semantically it is the same thing
you propose.

An alternate convention is required here (saying "varies on the docs"
is a valid answer).

> 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). 

Not really.  You just need to be able to trace ref/unrefs.  And write
some tools to manipulate data generated from a debugging run.  Sure,
not the perfect solution, but much better than a semi-broken
convention.

Speaking of which, what is the Microsoft standard for this, is there
any?

> 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.

The inout is not part of any spec I can find in my COM books that i
have here, and I would doubt that they did something as stupid as
unrefing an in parameter for the inout case.  And if they did, then I
would agree with some people that some Microsoft hackers do stupid
things. 

Miguel.

[1] (unless you are the owner of the object and doing it for
completely unrelated reasons to this argument).

[1.x]
The ref/unref rule is simple: you ref if you are going to keep a
reference to an object across a processing boundary, you unref when
you are done.