On Thu, Feb 21, 2002 at 06:19:18PM -0500, Greg Hudson wrote:
> 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?)
Yes, there are fewer drivers.
> > 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.
Yes, but I believe it will be harder for a new driver to get it wrong
(because it needs to construct and/or pass these new values) than for a new
editor to get it wrong [with the old interface]. There isn't anything in the
old interface that implies a particular policy.
It is nice to say "well, that's great. we don't want to impose a policy."
But that is a fallacy: we *do* want to say "use a subpool for your
file-related data because I'm going to process 1 million files, and I need a
way to clear unneeded data after processing each one."
This goes back to the paradigm of "the caller imposes the lifetime / memory
management policy." IOW, "put your stuff in this pool, I'll take care of
tossing it when I know the time is right."
>...
> 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.
And I wrote:
> I'm totally fine with using a pool cleanups as control points. But if people
> wouldn't mind doing *both* a close_FOO and a pool destroy, then we could
> keep the close functions.
Which is an unclear way of saying, "I'm fine with cleanups, but am also fine
with the explicit calls." The reasoning for explicitness is exactly as you
say: avoid obfuscation. That's why I went and ripped all the feedback table
crap out. It is non-obvious what was happening. In a similar vein, I also
observed that the use of the cleanup can also be non-obvious. But figured
that avoiding the second call on the driver side would be "neat". hehe...
maybe I should just say, "yah. you caught me. let's be clear rather than
neat." :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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