[Top][All Lists]
[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
- [Monotone-devel] automate stdio, really, Richard Levitte - VMS Whacker, 2006/08/30
- Re: [Monotone-devel] automate stdio, really, Jon Bright, 2006/08/30
- Re: [Monotone-devel] automate stdio, really, Timothy Brownawell, 2006/08/30
- Re: [Monotone-devel] automate stdio, really, Thomas Moschny, 2006/08/30
- Re: [Monotone-devel] automate stdio, really,
Nathaniel Smith <=