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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 29 03:23:14 2003