Re: Proxy objects and circular garbage

["Daniel Solaz" <dsolaz sistelcom com>]

Still thinking about this, and how to do it with the tools we have
*now*.
Instead of having proxy objects that are created and destroyed, and
trying to find out if the GtkWidget beneath should still be there (or
that it is gone), how about splitting this in two?
At the lower level, a 'true' proxy object, a native object that creates
a GtkWidget when it is allocated and *destroys* it when it is collected.
On top of this, what the non-C-language sees as widgets are in fact
references to this proxy. Apart from these widgets, no strong references
to the proxy, I suppose. Then all I need is a way to find out the proxy
object pointing to a given GtkWidget; no GtkWidget gets more than one
proxy and so just one reference. Hopefully the garbage collector will
make it all go well. It breaks cycles from the outside.
Access to the GtkWidget is done in the usual way
(nativeWidget->proxy->gtkWidget). High-level widgets don't share
ADDRESSes to low-level widgets, but references to the proxy. The proxy
could even track its clients. It can even hold some state.
Still have to see how this goes with callbacks.
Even before I start coding, please think about this and tell me of any
weak points you see. I just had this idea (and it shows) and sure there
are plenty.
-Daniel