Re: [Monotone-devel] automate stdio, really

[hendrik]

On Wed, Aug 30, 2006 at 07:15:41AM -0700, Nathaniel Smith wrote:
> On Wed, Aug 30, 2006 at 02:25:33PM +0200, Richard Levitte - VMS Whacker wrote:
> > Hi,
> > 
> > I just looked at today's IRC log, and saw a discussion about making a
> > "automate commit" command.
> > 
> > Isn't this going a bit far?  Soon, we will have automate commands for
> > all "normal" commands if we continue like this.  Isn't that getting a
> > bit ridiculous, not to mention the risks involved, like having to
> > update the same command in two places all the time?
> > 
> > I dunno what the solution is.  Maybe have stdio work with non-automate
> > commands as well, and having all commands be able to output stdio-
> > specific data that would be more oriented for scripts, as well as
> > human readable output, all depending on how the command was called.
> 
> Oh, well, the solution to duplicate code isn't removing functionality,
> it's refactoring :-).
> 
> There is some real work to do in making things work in automate, as
> well -- i.e., working out precise specifications of what goes in, what
> comes out, and what error conditions exist.  Basically, it's more like
> designing an API than a user interface.
> 
> By lucky coincidence, the proper way to design a flexible API is also
> refactoring :-).
> 
> I think the fantasy world trajectory is:
>   * people keep designing and adding new automate commands
>   * in doing so, they work out a set of clean, orthogonal operations
>     that cover the span of needed functionality
>   * as this occurs, internal code gets refactored and reorganized, to
>     also fall along the lines of the orthogonal operations identified
>     in the previous step (NB, some parts of the automate interface
>     already are straight exposures of internal primitives -- e.g.,
>     erase_ancestors, select, ...).
>   * as internal code gets refactored, normal command implementations
>     simplify
> Finally, we get automate as a paper-thin layer over nicely factored
> internal APIs, and user-interface commands as UI code plus calls to
> the same APIs.  End result: that nice separation of UI and logic that
> people call for, without having to stop and rewrite everything in one
> swell foop.
> 
> Will it work out like this?  I dunno, but it doesn't seem like it can
> hurt :-).

It might help to classify the source files (perhaps marking them with stardard 
grep-recognisable comments) as belonging to the library, the rest, or 
straddling the fence.  Fence-straddlers can then be picked apart one at a 
time as convenient until the codebase reaches a state where it cleaves asunder 
easily.

We could achieve a library without having to stop other development for 
six months.  

It might be the kind of thing I'd like to be doing if I find time.

[though it would be more fun designing automated tools that do this kind of 
thing ... I'm in incorrigible metaprogrammer ... But that wouldn't get the job 
done in reasonable time :(
]

-- hendrik