Re: Mini-issue: boolean config values

Files wrote:

>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.
>
>
No, it does not have to change. Why would it have to change?

>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.
>
>
Performance is not the issue. Code duplication is and clarity are..

>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.
>
>
Exactly, and with the two new functions we can get rid of that checking.

>If you like, I can encapsulate the comparator as well.
>
>
Already done.

>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?
>
>
No, not once -- it should happen in one place, which is a bit different.

>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.
>
>
The parser must not try to interpret the meaning of the options, only
their values.

-- 
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