RFC: escape strings in KConfigBase

[Andreas Hartmetz]

On Tuesday 15 May 2007 22:09:55 Oswald Buddenhagen wrote:
> On Tue, May 15, 2007 at 09:01:02PM +0200, Andreas Hartmetz wrote:
> > On Tuesday 15 May 2007 19:49:26 Oswald Buddenhagen wrote:
> > > On Tue, May 15, 2007 at 06:49:51PM +0200, Andreas Hartmetz wrote:
> > > > Compatibility with - old KDE versions, the desktop file
> > > > specification, (...)?
> > >
> > > both, one would think.
> >
> > I just think that a little backwards compatibility here and there will
> > together make your software much worse in the long run. If you
> > wouldn't have done it the same way now, time to change.
>
> that's actually my position (patent pending; i'll sue you later for
> infringement). it just happens to be a hard sell.
>
> > KDesktop file should, of course, conform to the spec. No problem -
> > just don't make it inherit KConfigBase, or add any special cases to
> > KDesktopFile.
>
> i tend to think inheriting kcb and passing an option to inibackend is
> the cleaner and simpler way.
>
> > > 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.
> >
> > Oh no, a function call!
> > That really changes everything. I mean, why do you bring irrelevant
> > arguments?
>
> this is silly. intentionally separating the quotes at the wrong places
> and thus distorting the context to make a point is dishonest.
>
OK, I tried to cut out only irrelevant text - i'm sorry if that went wrong. 
Editing quotes for your own advantage is evil and stuff.

> > > it might be not much effort to add,
> > >
> > > but interpreting any escapes could definitely change the semantics
> > > of some existing keys.
> >
> > Find me one. I didn' find any in my ~/.kde/share/config at least.
>
> lack of evidence is no evidence for a lack. wait, i read that just some
> hours ago ...
>
> > > 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
> > > ...
> >
> > Tradition is great for tourists and museums, and it has nothing to do
> > with good API design.
>
> "your" feature comes at a price: cpu time (un-/escaping),
> incompatibility, potential for bugs (which in the worst case are
> discovered after the 4.0 release and need incompatible changes for
> fixing) - so it would be counterproductive to design an api for an
> non-existing use case.
>
Exactly, use cases.
What I was originally expecting to see in this thread.

To anyone reading: Use cases please.
Have you ever had problems with disallowed chars or list delimiter chars in 
input to KConfig/KConfigBase? Here is where this might get fixed in a general 
way.

Two use cases exist:
Case one:
again out of context, let's keep this mail under 100k,
Olivier Goffart "I also already had the problem /[ed: list separator chars in 
values]/ (in my case this was with ',' in lists)"

Case two:
me, who wants to store Q/Kactions' names and application names as keys in a 
config file. Now actions have almost no restrictions on their names, and I'd 
have to write an escape function that could be needed in other situations, 
too. So I thought, logical place for the escape function: kdelibs. This use 
case is also in kdelibs, which isn't very relevant here except for code size 
issues.

> > You are acting like a museums' guard.
>
> actually, i'm just playing devil's advocate. i'm practicing for being a
> trolltech employee, you know. >8=)

Smiley contest!
What if I was the devil? }8&]=