On Wed, 2009-11-18 at 11:30 -0800, Zach Welch wrote: > On Wed, 2009-11-18 at 11:07 -0700, David Brownell wrote: > > It gets annoying to need to recall which variant of > > true/false a given routine needs. :) > > It's part of a generally good rule too: be forgiving with what you > accept for input, and strict with what you emit for output.
In following this rule, I added another patch to accept any valid input, while continuing to display the particular pair of choices that were provided by the "variant" macros. It's all of five lines changed. :) While the variants may be annoying, they serve to benefit the user while remaining easy for developers to use; I am not sure how to make things any easier. The key point here is that they display the command error output to the user, eliminating redundant code in its various callers. We should be strict about what we emit to the user here, even though we will accept anything. Our emissions include error messages. Usually, there will be one particular pair (on/off, enable/disable) that will be most appropriate when considering specific use cases, and any error output will provide the suggested terms to use in your scripts. Also, this avoids the need to update each command's documentation, as the output remains consistent (and resonates) with it. Does that sell them? :) --Z _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
