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. 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. Thanks -Ben On 12/22/06, Thomas Keller <[EMAIL PROTECTED]> wrote:
Nathaniel J. Smith schrieb: > On Thu, Dec 21, 2006 at 03:04:22PM -0500, Ben Walton wrote: >> I cooked this up today as a corollary to get_option. I hope it's useful. > > So, umm... before investing time in reviewing the patch, rewriting > internal interfaces, answering future support questions, etc... _do_ > you have any ideas where it would be useful? Because I'm not really > sure myself (_MTN/options is really an implementation detail kind of > thing, and now that I think about it get_option is really unlikely to > survive into mtn 1.0), and it seems silly to spend that time unless > it's plausible that there will be commensurate rewards? Don't get me wrong, but how is he supposed to know that? Maybe we should start and explicitely name / comment certain things as "temporary, will be replaced", so no manpower goes into that? In the end get_option as well as set_option is just some interface to something which has been introduced into monotone for some time (workspace options), probably long before I knew monotone, but didn't get proper UI support until now. IMHO there are use cases when get/set_option is useful, now the question is if these use cases should get support or if we should throw them over because they're just of temporary nature? Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.berlios.de > Music lyrics and more: http://musicmademe.com
-- --------------------------------------------------------------------------------------------------------------------------- Ben Walton <[EMAIL PROTECTED]> Unanswered questions are far less dangerous than unquestioned answers. - The Roadside Pulpit --------------------------------------------------------------------------------------------------------------------------- _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel