[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mini-issue: boolean config values

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-10-29 03:22:31 CET

Files wrote:

>I was thinking simpler.
>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
And that's simpler?

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.