On Thu, 2002-02-21 at 16:51, Greg Stein wrote:
> The new interface makes it easier for the editors to Do It Right. Currently,
> all the editor implementations must deal with the subpool stuff, or else
> they will be doing it wrong.
> Essentially, it encodes the memory "policy" into the interface, rather than
> just hoping that editors will get it right.
Er, more precisely: the new interface puts the memory policy into the
editor driver, instead of the editor implementation. If there are fewer
drivers than editors, I suppose that's a win. (Is that true, though?)
> I'm thinking that encoding the discipline into the interface will get us
> away from this problem permanently.
Fixing all the editors will solve this problem. Making all the drivers
do the work instead will solve the problem. Neither solution is
terribly permanent; a new editor or new driver could certainly do it
wrong.
> > This would totally screw the XML output
> > editor, for instance, unless you assume that the caller is doing pool
> > management in a very specific way.
> It can definitely be assumed that the pools will be tossed in a nested
> fashion. That is part of the interface, and using cleanups is explicitly
> provided.
"In a nested fashion" is necessary but not sufficient. The close_*
handlers for the XML output editor actually write data, so you have to
close one file baton before opening the next. Sure, you can tell the
caller "you have to free the pool you provided for the last file baton
before opening a new file baton," but to me, that's using pools to
obscure the program's flow of control.
Put another way: at least for the XML editor, closing a baton isn't just
about cleaning up resources; it's about taking action. Making that
action go through a pool cleanup handler is confusing; the reader of a
program doesn't expect pool destruction to be where the interesting
stuff happens.
Cleanup handlers are nice when they mean you don't have to worry about
whether a resource will eventually freed up; at some point, the caller
will release the pool or one of its parents, and that will take care of
it. But if you've already told the caller "you must specifically free
this pool at this particular time so that this cleanup handler will be
invoked," you aren't taking advantage of cleanup handlers; you are
employing gadgetry to save a few lines of code at the expense of its
clarity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006