Re: Proposal: Ref Counting Conventions

[Maciej Stachowiak <mjs eazel com>]

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

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

Will send patches here as time permits.
 
> > 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.

The example that I cited is the one that flowed freely into my mind,
it seems like the general case.

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

I'm confused about why you object to the convention then, since
adopting it won't require changing anything that exists.

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

That may be true of out parameters, but I think inout parameters are
designed to model call by reference, not multiple return values.
 
> 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.

Well, whoever came up with the MS convention does not think so, and I
assume he or she has more experience with inout parameters than we
do. Are you claiming always_replace or never_replace is the most
common use case for inout parameters?
 
> 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).

I still think an inout parameter is siginifcantly different.

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

Give me an example of a non-broken usage of an inout parameter then.

Personally, I think inout parameters are really confusing and should
not be used at all, but if we are going to have them, we'd better
handle them right.

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

I think the idea is that when you use an inout parameter and replace
the value, the client code is implicitly dropping a ref to the old
object and gaining a ref to the new object. 

Really this is the only thing that works in the general case because
the IDL cannot guarantee whether an inout parameter will be always
replaced, never replaced, or sometimes replaced. It should be possible
to write client code without caring.

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

I don't think I want to argue about this any more because mainly my
opinion of inout parameters is that they suck and should not be used
anyway. Various authorities on CORBA agree with the fact that inout
sucks.

 - Maciej