RFC: escape strings in KConfigBase

[Oswald Buddenhagen]

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.

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

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

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