Re: Mini-issue: boolean config values

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
make the yes stringbuf a 0x3100 and the no stringbuf 0x00 (empty string).

Comparison is only required for the first characrter.

Duplication occurs where? Seriously, we check for 'yes' and 'no' all over the
place. I'm not getting the issue unless I'm missing something. The main
problem is that the config hash takes a string value for a result.

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'
thing is supposedly supposed to be propagated and repeatedly compared all over
the place. That's bothering me.

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
it is?

All I'm objecting to is that the non-parsing parts of the code knows too much
about what is true and false. Maybe we're coming at the same issue from two
angles.

-- 
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org