Ben Collins-Sussman <sussman@newton.ch.collab.net> writes:
> And along this line of thought, perhaps the editor funcs might take a
> *2nd* pool for doing 'scratchwork'; think about it. Every
> editor-driver is going to be looping over entries and will have a
> 'scratch' pool per-iteration -- why not let the editor use it too?
> The lifetimes match up. It's kind of redundant to have the editor
> creating and destroying a scratch pool internally.
>
> Thoughts?
Mmmm. Well, first thought: I don't see the need for the scratchpools.
If an editor function's code has loops, then it can follow the same
pool/loop conventions as anything else...
...this is irrelevant, but isn't it interesting that the words
"pool" and "loop" are reverses of each other?...
...so at a maximum, an editor function should only take one pool
argument. If the function has a loop inside it, it will create a
subpool of whatever pool it has at hand, loop, using and clearing that
subpool repeatedly, and then destroy the subpool.
However, I'm wondering whether the editor API needs any change at all
for pools. It's true that the functions take batons, not pools, and
the only place you get a chance to pass in a pool is when you create
the editor and its edit_baton... But, consider: editor functions
don't really get called in loops with arbitrary numbers of iterations.
Sure, there may be a loop here or there that can end up doing several
replace_foo calls in sequence, but basically editors are driven in a
depth-first, nesty way, which is the opposite of a flat, iterative
way.
I think the editor might be a case where per-object (i.e., per-baton)
pools are the right way to go. For editors, the close_foo functions
are needed as part of the editor semantics; while they are sometimes
used for pool freeing, they are also used to finalize operations,
print out information, etc, etc.
If we pass a pool into each editor function, we make an assumption
about what that function does. But the whole point of opaque batons
is that the driver doesn't really need to know what the function does.
We have functions that in some editors use a pool, and in other
editors don't use any pools. If a pool were passed in explicitly to
the latter, that pool would just have to be ignored.
I think the editor semantics as they currently are enforce exactly the
scope we want for each operation, by virtue of baton lifetimes. Which
happens to map very well onto pool usage, for those cases where the
baton contains a pool.
I'm definitely for the overall pool usage change, and for absorbing
Greg's principles about how to use pools generally. But in this one
case, it seems to me that we're getting exactly what we want, and if
we attempt to bring the editors into line with that principle, we'll
only end up realizing that the *true* principle is something a bit
more subtle than we thought, maybe something like:
When the caller's loop defines an object's lifetime, then don't use
a per-object pool, use a per-iteration pool. But when the object's
lifetime is well-scoped by the calling discipline of the functions
that use that object, then a per-object pool is appropriate.
...or something close to that.
Just because I can't state it elegantly doesn't mean it's not
there. :-)
-K
Received on Sat Oct 21 14:36:28 2006