Re: Proposal: Ref Counting Conventions (REOPENED :))

[Mike Fleming <mfleming eazel com>]

Issues surrounding Bonobo object reference counting and how this relates
to GTK objects seems really murky to me.  I didn't fully realize the
murkiness of these waters when I initiated this discussion or
presumptuously pronounced it as "closed." :)  I do continue to believe
that these conventions can be valuable if we can agree on their scope
and follow them consistently.

To begin with, these conventions apply only to Bonobo::Unknown ref() and
unref(), not to the reference counting of GtkObject's.  With that said,
there's still a lot of confusing territory surrounding BonoboObject's
and the two reference counts.

I propose initially that we limit the scope of these conventions to *raw
CORBA calls only*.  Any time you call a function that has been generated
from the ORBit IDL compiler--or implement the server side of such a
function--you should follow these conventions for all CORBA_Objects that
implement Bonobo::Unknown.

Currently excused from these conventions are non-language binding
functions that return or accept CORBA_Object's (ex:
bonobo_object_corba_objref).  I'd like to suggest that we move towards
encompassing these functions as well, and follow the conventions
consistently for *all* manipulations of CORBA_Object that implement
Bonobo::Unknown's.

But now I'm more confused -- I just browsed through some of the Bonobo
implementations (ControlFrame, Container, ClientSite) and couldn't find
any CORBA methods implementations that ref()'d objects they return.  Am
I looking at this wrong?

Mike Fleming

Maciej Stachowiak wrote:
> 
> Miguel de Icaza <miguel@helixcode.com> writes:
> 
> > Darin,
> >
> >    You raise a good point, and I think we need to continue the debate
> > from where we are now.
> >
> >    Michael's proposal only covers the CORBA level: how reference
> > counting works at the Bonobo::Unknown level.  It does not cover other
> > uses of it.  Ie, the reference counting applies to objects that are
> > returned over a CORBA call boundary.
> >
> >    For instance:
> >
> > >     bonobo_object_from_servant
> > >     bonobo_object_get_servant
> > >     bonobo_object_activate_servant
> > >     bonobo_object_corba_objref
> >
> >    These are utility functions from the CORBA/Gtk merging land: none
> > of those return objects that were returned from a remote component,
> > they are simply routines that return the values you already "own".
> >
> >    Besides object_from_servant is again, just a utility function that
> > maps the CORBA servants to the CORBA object references.
> >
> > >     bonobo_embeddable_construct_full
> > >     bonobo_embeddable_construct
> >
> > These again, do not invoke any remote methods.  Note that these
> > methods return the GtkObject fully constructed or NULL.  They do not
> > return a Bonobo_Unkonwn that was returned from a remote method or
> > CORBA_OBJECT_NIL.
> >
> 
> I already know what Darin's objection is going to be, so I'll state it
> for him.
> 
> Drawing the distinction this way requires client code to know which
> GtkObject methods invoke CORBA methods; thus, it's still necessary to
> know method-specific information to see at a glance if refcounting in
> the code is correct. This pratly defeats the purpose of having the
> refcounting convention in the first place.
> 
> I do agree that making the methods mentioned ref the return value
> would be extremely weird however.
> 
>  - Maciej
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list