Re: Proposal: Ref Counting Conventions

[Miguel de Icaza <miguel helixcode com>]

> > Thanks for pointing this out.  Can you file a bug report for Bonobo in
> > this case, or better yet, submit a bug report?
> 
> I assume you meant "a patch". I'd be glad to fix all Bonobo methods
> that return Bonobo objects to ref them first if you agreeit is the
> right thing to do. Maybe Michael can help, since he is the one who
> brought this convention to our attention.

Oops.  Yes, I meant that.  Thanks a lot.

> Please at least try to understand the rationale before panning it.
> Let me try to give another example:

I did think about it.  If I did not write more, is because I thought
my examples were enough, and because I assumed that the example would
flow freely into hacker minds.

Obviously there *might* be cases in which you take an object, and
return a different one.  But the first question is: how often is this
going to be the case?  How many samples of this do we have?

Bonobo has no Unknown/based inout parameter, and I do not see any in
Nautilus either.  The added complexity for these cases is minimal. 

And this new convention changes the fact that an out parameter is just
a hack for the fact that C-based languages do not deal with
multiple return values properly.

----------------------------------

Your example is well suited for the case of "Change_or_replace", but
I sustain it is an uncommon case, and I sustain that it is a breakage
from the base for ref/unref usage.

I rather add 2 more lines of code for comparing identity of an object
and make the ownership issues very very clear in the source code for
the sake of consistency with the model I outlined before (the fact
that an out parameter is nothing more than a return value).

>  // much uglier than the last version

Much uglier means 2 lines more of code, and one temporary variable.

I really can not think of a situation where we could use this kind of
interfaces, but it seems that if you resort to that, you really need
to think again your interfaces in the first place.

So, to sum it up:

	1. I do not like the inout unrefs on server trick because it
           breaks the clean use of ref/unref:

		a. ref when you want to keep a reference.
		b. unref when you are done with your reference (more
		   verbose text on the previous mail).

	2. Because I do not think 2 lines of extra code for a broken
           interface is too bad.  You might just redo the interface to
           begin with.

Love,
Miguel.