Re: Introducing "toggle references"



On Tue, 2005-04-26 at 10:59 -0400, Owen Taylor wrote:
> On Tue, 2005-04-26 at 15:36 +0100, Mark McLoughlin wrote:

> > 
> > 	If so, then what's really hurting my brain is the fact that the
> > reference add_toggle_ref() takes isn't the reference which toggles
> > between weak and strong; its actually the reference from the object to
> > the proxy which toggles.
> 
> I guess my mental conception is that a "toggle reference" is actually
> a bidirectional link between the two objects... the two references
> are related in intimate ways (see my fix to your example above) and
> are not independent.

	That makes some more sense.

> The part that g_object_add_toggle_ref() actually creates is the part
> that is implementable in GObject ... it has to be supplemented with
> code specific to the other garbage collection system.
> 
> (other than for example purposes proxying together two GObjects probably
> isn't that useful in general, though I won't say its' *never* useful)

	Yep.

> > 	Also, would it not make sense for add_toggle_ref() to return the
> > reference?
> 
> I'm not sure what you mean by the 'reference' - the reference count?

	The pointer to the object we've just taken a reference of - i.e. I'd
expect it to mirror g_object_ref() rather than gobject_weak_ref().

	Which reminds me - does having GToggleNotify mirroring GWeakNotify
really help? They seem unnaturally reversed with GWeakNotify, but it
helps because the data pointer is the most interesting argument to the
callback in practice (e.g. with g_nullify_pointer()). But with
GToggleNotify, both arguments are interesting in the callback.

> > 	I guess explicitly maintaining the weak reference from the object to
> > the proxy is fairly superflous in this example too ...
> 
> I think it's something you generally want. 

	I guess all I was saying is that both objects are guaranteed to be in
the process of being garbage collected when weak_ref_notify() is called
- so removing the toggle ref and dropping the weak ref is purely
superflous housekeeping.

	(Not that its not good practice and makes the code easier to verify
etc.)

Cheers,
Mark.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]