On Thu May 03 21:02:21 2007, allison <!-- x --> at perl.org wrote: > Andy Dougherty wrote: > > On Tue, 1 May 2007, James Keenan via RT wrote: > > > >> On Tue Apr 10 01:45:31 2007, jrisom <!-- x --> at gmail.com wrote: > >>> Configure should act as though writing --foo=no is false instead of > >>> true. Tonight I tried using --execcapable=no to get around a compile > >>> failure, but then realized that it would probably treat "no" as a true > >>> value. > > I'm okay with having a plain English representation for "false value", > as long as we have exactly one. Pick 'no', 'none', 'false', or whatever > but we won't try to support every possible value a user might type in to > mean false. Whatever we pick will mean false everywhere, on every > option. And we have to be careful to make sure it's not a value that > someone might want to use as a string value. >
The more you multiply variant ways of providing values to options, -- the more code you have to write, -- the more code someone has to maintain, -- the more tests someone has to write to verify the validity of the code and ensure high coverage by the tests, and -- the more documentation someone has to write to explain the code. For at least the third of those tasks, that someone, currently, is me. If we choose to support "yes" and "no" where "1" and "0" would suffice, then I have to write additional tests to test that code. That's more work for me -- but it also means that you, the Parrot developer, have to wait longer and longer for 'make test' to run. I'm hoping to recruit additional people to help maintain Parrot's Perl 5 configuration and build tools, and I made some progress in this regard at Hackathon Toronto. Still, almost all of Configure.pl's options are completely untouched by the test suite. Code coverage for the config/*/*.pm hierarchy is generally only around 25%. Why multiply features for which, if we're following best practices, we ought to write tests when we don't have the people to write those tests? If the values available for a given option logically reduce to a Boolean, then reduce the possible values to "1" and "0". Then, document them and test them. kid51
