RFC: escape strings in KConfigBase

[Andreas Hartmetz]

On Tuesday 15 May 2007 16:28:28 Oswald Buddenhagen wrote:
> On Tue, May 15, 2007 at 11:30:59AM +0200, Andreas Hartmetz wrote:
> > On Tuesday 15 May 2007 10:19:59 Thiago Macieira wrote:
> > > You don't save user strings in keys. If your program is doing that, I
> > > submit that you should redesign it.
> >
> > Yeah I don't, actually. But what is to be won by imposing restrictions on
> > keys' names?
>
> back then simplicity, now compatibility ...
>
Compatibility with - old KDE versions, the desktop file specification, (...)? 
Simplicity of implementation doesn't count if the extra work would be minor, 
as it is the case here.
KConfigBase at the moment is NOT compatible with the desktop file standard and 
so KDesktopFile isn't, either.
Incompatibilities are the list delimiter char (the default one) and (surprise) 
legal desktop file escape sequences not supported by KConfigBase, 
specifically \s, \n, \t, \r.

> > Suppose that you let users define configurable little things and your
> > users are also allowed to name them. The little things will be nicely
> > separated from the rest of your settings by putting them in their own
> > group. Now you have to make up names like "item0001" and put the name
> > in the value.
>
> hmm, yes. that's what was always used so far.
>
> > If you want to access your items by name and it should be fast, you
> > now have to use another QHash in your program.
>
> if you want it to be fast you would probably preprocess the config anyway.
> and since when is working with strings fast?
>
Accessing strings by hash or map is much faster than comparing them one by 
one, and if KConfig does that for you, you don't have to.
Basically, you are saying "dealing with strings is slow, so who cares if it's 
even slower?".
You'd have one mostly useless hash/map in KConfigBase and one more useful hash 
in the application. Extra work for programmers, OK, but you get the benefit 
of using more memory and CPU cycles too! Wow!

> > "The escape sequences \s, \n, \t, \r, and \\ are supported, meaning ASCII
> > space, newline, tab, carriage return, and backslash, respectively." [1]
> >
> > They could have gone the extra millimeter and allow escapting of [,],=,#
> > but nooo...
>
> escapes are only supported in values, not in keys (at least in kconfig).
> i'm not saying this is perfect, but your line of argumentation falls
> flat. ;)
>
If you say so, it must be true! (Seriously, I can't follow your line of 
argumentation.)
I am simply saying that forcing programmers to care *at all* about what they 
pass to KConfigBase is bad. Covenience is, among other things, not having to 
care.

> > "Some keys can have multiple values; these should be separated by a
> > semicolon. Those keys which have several values should have a semicolon
> > as the trailing character. Semicolons in these values need to be escaped
> > using \;"
> >
> > Another thing to notice is that desktop files and KDE actually use
> > different list entry delimiters by default (';' vs. ','), and that the
> > spec says that lists should have a trailing ';'. [2]
>
> the delimiter can be passed to the list reading/writing functions.
> note that only values that are actually supposed to be lists are
> separator-escaped.

See above, not having to care and so on...
And who reads the desktop file spec before using KConfig, anyway?