monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] automate stdio, really


From: Nathaniel Smith
Subject: Re: [Monotone-devel] automate stdio, really
Date: Wed, 30 Aug 2006 07:15:41 -0700
User-agent: Mutt/1.5.12-2006-07-14

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 :-).

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould




reply via email to

[Prev in Thread] Current Thread [Next in Thread]