Created attachment 46174 [details] [review]
Add 'traverse' virtual method to GObject

Just one more remark.  This 'traverse' function should obey the following
constraints:
  1. should yield only referenced GObject's for which a strong parent-child
relationship exists;
  2. for each GObject, there must be only one other GObject that can really be
considered its owner/parent;

Following these rules, the graph constructed by g_object_traverse must be
strictly a tree, and the all the trees formed from all possible root objects
must not intersect with one another.

The best example of this is the GtkContainer->GtkWidget relationship. 
GtkContainer::forall is perfect, except that we need something more generic at
gobject level.  In particular, GStreamer will also need this.

I think if we add the concept of containers and ownership to gobject, it would
probably be a separate GContainer interface. We may want to add things like
child properties. Regarding the proposed traverse function, it sounds a bit weak
to me to merely document the requirement that the traversal links form a
collection of trees, without having an explicit concept of ownership, and
something like g_object_get_owner(). Also, it is not at all clear to me where
the traversal should go and where it shouldn't. Does it include "internal"
objects which are just implementation details ? In the case of composite
children in complex widgets, probably yes. In general, probably no. 

OK, I understand your concerns.  I would like something like this at GLib level,
although the exact form is subject to discussion of course.

The reason why I think this should be in GObject and not in pygtk is two-fold:
  1. PyGTK should not have to be aware of all parent-child relationships in
3rd-party libraries, like GStreamer; the libraries themselves should supply this
information;
  2. If PyGTK needs this information, there is some chance this problem does or
will occur with other bindings.

Speaking from the point of view of the PyGTK requirements, I think "internal"
objects should not be included in the traversal.  What we need is to include
contained objects that may potentially be exposed through some API.  Since
objects that are never exposed to the programmer do not have any chance of being
wrapped as PyObjects, they have no chance to participate in or contribute to
PyObject cycles, so we don't need them.  [I realize now that the GtkContainer
implementation in bug 303483 should be using foreach instead of forall]

Putting this as an interface is an interesting option too, although I hope it
doesn't make lookup slower...  also, do classes inherit interface
implementations too? I mean, in bug 303483 the virtual method is implemented for
GtkContainer, which makes it implemented automatically for all subclasses; would
interfaces have similar behaviour?

Hm.. sorry, I forgot about the Small API target..

(In reply to comment #0)
> In bug 303266, we came accross a scenario that needs a GObject virtual method
> in the spirit of Python's tp_traverse.  Just like gtk_container_forall, but at
> GObject level.

what you want in that bug report is a function that yields all object reference counts, not children of a container. i have commented in your report on why this is not suitable and recommend to simply use g_object_dispose() which was introduced to clear the reference cycles you ran into.

(In reply to comment #2)
> Just one more remark.  This 'traverse' function should obey the following
> constraints:
>   1. should yield only referenced GObject's for which a strong parent-child
> relationship exists;
>   2. for each GObject, there must be only one other GObject that can really be
> considered its owner/parent;

first, this is not what you need to fix bug 303266, since non-child-parent references may exist. 
second, the guarantee you demand in 2 couldn't possibly be provided, GObject doesn't dictate a specific parent<->child model, people may validly implement multi-parent<->multi-child relationships in derived classes. for these traverse would be meaningless (so put it mildly). in any case, such a function belongs into the container implementation and no where else. and that's why GtkContainer currently has forall/foreach.

if what you want to propose is an actual implementation of a GChild and a GContainer interface for libgobject, then please open a new bug report.
the above notion of "traverse" is not applicable for GObject at least.

I didn't want to imply a child/parent relationship.  This is just a semantic issue.  What I meant was a way for an object to yield a list of references to other objects it contains.  Doesn't really matter who's the parent and who's the child, or if they're peers.