Re: [Monotone-devel] [PATCH] mtn automate set_option

[Nathaniel J. Smith]

On Fri, Dec 22, 2006 at 07:49:47PM -0500, Ben Walton wrote:
> Yah, I'm new, but I may be missing the point a little still.  When
> thinking in the context of wrapping mtn in a gui (the whole point of
> the automate commands), isn't it desirable to have a programmatic
> interface to things like the options file?
> 
> It's not a mainstream, everyday feature by any means, but if it's not
> in mtn, it would end up being duplicated in each gui that wraps mtn.
> Hiding inside the automate family of commands allows the mtn backend
> implementation to change without necessarily affecting the clients
> that use it.  If all of a sudden _MTN/options was to be called
> _MTN/options_v2, only mtn would need to be modified, not the gui
> wrappers, for example.  It could also hide renamed options, but
> accepting old_name || new_name as well, providing a migration path for
> clients to update their code.
>
> Apologies if I'm off base with my line of thinking.

No, this all makes perfect sense.  My concern isn't that the code
itself is broken, or that abstract interfaces are bad (though "poke
around in this internal table that was never designed especially to be
shown to the user" is maybe a little less abstract than it could be).

The problem is, it is basically always a bad idea to build an
interface because you know it will be needed "someday".  You end up
with interfaces that are poorly adapted to whatever use cases they
eventually end up with -- except when the interface or implementation
thereof gets made obsolete before you even _get_ users, in which case
your work gets wasted entirely.  And, of course, there are generally
lots of other things that are needed "now", that one is necessarily
putting aside to work on things that are only needed "someday"
(a.k.a. opportunity cost).  (The canonical reference for this
argument, of course, is http://c2.com/xp/YouArentGonnaNeedIt.html .)

Also, even if we do need it "now", it is usually worth at least
articulating why that might be (hence all my ranting about use cases)
:-).

None of which, of course, says you can't work on whatever you want to
(err, how could I stop you?), or that you should go around all the
time like some crazed economist caricature asking yourself, "is my
current resource allocation _maximally efficient_?" (man, that would
just suck all the fun right out of it).

> Also, I'm just looking for more things to hack on to get into the code
> more.  If my patches aren't useful, that's ok.  I've learned more
> about mtn by writing them, so they're still useful to me, if only as
> an exercise.

Yeah, sure, of course.  Definitely don't want to discourage you :-).
And I'm not saying they _aren't_ useful, just trying to generate
useful discussion and maybe provoke useful thoughts.

-- Nathaniel