Karl Fogel <kfogel@galois.collab.net> writes:
> The only solution I can see is to pass a factory function into
> the crawler and having it dynamically generate the editor at the
> time when it formerly called replace_root(). I tried writing a
> prototype and doc string for the new crawler, and while the
> resulting interface wasn't particularly awful on their face, the
> implications for existing callers really weren't pretty. The
> commit editor is usually composed with a trace_editor or two;
> now instead of doing the composition up front and passing the
> result as a ready-to-use tool to whoever needs it, we'd have to
> defer it into the callee, and any context required for the
> creation of the editor would have to be wrapped up in a baton
> and passed along as part of a factory closure to the editor
> driver. Haven't we got enough of that going on already?
I should note that JimB pointed out (on the phone) that a factory
function isn't the only solution here.
Another solution is to not worry about the side effects of creating an
editor unnecessarily. It might generate some extra output, say,
useless network traffic, in the case of a commit that ends up not
happening because no local changes, but that should be harmless.
(My own feeling is that such behavior would be strange, though by no
means a showstopper. If there are no local changes, then the driver
shouldn't do anything. Here, "doing something" is defined as "calling
an editor function", a definition that's easy to state and remember.)
Anyway, I wanted to at least mention Jim's point, to better represent
the choices before us.
-K
Received on Sat Oct 21 14:36:21 2006