My solution was to define a new vtable method--I've called it visit(), though the name's not the important part--to which you pass a callback (plus an optional context argument). It's job is to invoke that callback on each of it's referenced "children" (also passing the context object with each invocation), and that's it. The PMC doesn't know or care what the callback does--in a GC context the callback may set a flag on what's passed in and stash it for later processing; in another context it may be used inside of an iterator which vends out objects one-by-one and guards against loops.
Great! This is exactly the fundamental operation I'd been musing would be the best building block to enable serialization and pretty-print operations, and I'm sad to see that your post has been Warnocked. :(
This mechanism is excellent in that it enables both breadth-first and depth-first traversals, and is neutral to whether a pointer is traversed or not: The client (callback) can decide that based upon the live bit or the ordered destruction bit or a seen table or the phase of the moon. This also doesn't alone imply any resource consumption. And it doesn't affect concurrency; threading is preserved. Great!
Serialization is a very natural client of this API, and at least some of the arguments surrounding serialization should be lessened—because the core technology is amenable to use by various possible algorithms, and so deciding upon those algorithms early becomes less vital. Serialization simply becomes an easier problem with this in place.
I would venture, though, that DoD may well need a separate and heavily optimized implementation, purely for efficiency's sake.
—
Gordon Henriksen [EMAIL PROTECTED]
