Re: Mini-issue: boolean config values
From: Files <files_at_poetryunlimited.com>
Date: 2003-10-29 05:01:40 CET
Maybe I'm not being clear.
Maybe I need to be more so.
When you add options, your config_file.c needs to change anyway.
Therefore you simply add the name of your boolean to it.
In the other places, when you compare for values, I'm almost tempted to simply
Comparison is only required for the first characrter.
Duplication occurs where? Seriously, we check for 'yes' and 'no' all over the
If you like, I can encapsulate the comparator as well.
Somehow I'm not getting it. What I *am* seeing is that this whole 'yes'/'no'
Parsing/string comparison for booleans should happen once. No?
Maybe I should code it up, and show you the patch and let you decide how bad
All I'm objecting to is that the non-parsing parts of the code knows too much
-- Shamim Islam BA BS Branko ?ibej said: > Files wrote: > >>I was thinking simpler. >> >>config_file.c >> >>hash containing all boolean options (function secret) >>stringbuf w/ yes and no.(parse-context values) >> >>static function is_boolean to check to see if the option is a boolean one. >> >>static function conform_boolean to do the translation based on is_boolean. >> >>When an option value is parsed if the option is boolean, compare for truth >> and >>substitute the stringbuf above instead of the value when setting the option >>value in the config. >> >>Do this where the config hash for the option is set as a pass through. >> >>Then all of the comparisons can be simply 'yes'/'no' everywhere else. >> >>No mess, no fuss. >> >> > Aargh. This is badness. > > 1. You'd take a generic interface and put specific info into it. What > happens when new boolean options are added, and new config files? > 2. You'd be changing the values in the config context during parsing. > That's very non-intuitive > 3. Users of the config functions would still have to check the values > up front, causing code duplication all around. > > >>IMHO, the real problem is that we haven't set a policy for what a truth value >>should be on parsing. But parsing should know what is valid and invalid for a >>fixed set of keys which have limited context. >> >> > With my proposal, we don't _have_ to set a policy, we just recognize a > certain set of values. If 'on'/'off' suits a particular option better > than 'true'/false', then why not let the user chose which value to use? > That makes the config files self-documenting (to a point). > >>So the parser needs to be more intelligent and the comparators need to be >> more >>dumb. >> >> > And that's simpler? > >>Thoughts? >> >> > I'm testing the svn_config changes now. Expect a commit shortly. > > -- > Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/ > --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Wed Oct 29 05:02:20 2003
This is an archived mail posted to the Subversion Dev mailing list.