RFC: escape strings in KConfigBase

[Oswald Buddenhagen]

On Tue, May 15, 2007 at 06:49:51PM +0200, Andreas Hartmetz wrote:
> 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, (...)? 
>
both, one would think.

> 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
>
see bottom.

> (surprise) legal desktop file escape sequences not supported by
> KConfigBase, specifically \s, \n, \t, \r.
> 
indeed. because this is a storage backend detail and consequently
handled by kconfigini.

> > > 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,
>
you still have to calculate a hash of the string. for very small
collections of very different long strings this is even slower than a
linear search.

> Basically, you are saying "dealing with strings is slow, so who cares
> if it's even slower?".
>
yes. if you really want speed, you don't use strings. if you need to deal
with strings (because they are the primary object), some config lookups
are usually no problem. if you need to do lots of config lookups you are
better off crafting your own hash - kconfig has a lot of overhead in any
case.

> > > "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.)
>
keys don't support any escaping as of now. consequently adding more
escaping is no "millimeter", as it would mean adding escaping in the
first place. it might be not much effort to add, but interpreting any
escapes could definitely change the semantics of some existing keys.

> 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.
> 
keys are traditionally thought of as identifiers (in the c++ sense) -
i'm pretty sure this is what kalle was assuming when he wrote the code
>10 years ago. from here it really isn't much to think about ...

> And who reads the desktop file spec before using KConfig, anyway?
>
nobody. but arbitrary kconfig files are not supposed to be used as
desktop files. and if you handle desktop files with kconfig (as opposed
to kdesktopfile) you *really* should read the desktop entry spec.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.