[RFC] KConfig API stuff - amended proposal

[Allen Winter]

Howdy,

Any objections to this proposal from ossi?
I think we can allow this, no?

Please say so ASAP if you object. 
-Allen


On Monday 22 October 2007 09:03:40 am Oswald Buddenhagen wrote:
> given the massive resistance against a "proper" refactoring, here is a
> reduced proposal.
> these changes have practically zero potential to break anything, so i
> don't accept any "we are in release mode" type objections.
> as stated previously, i'd do all the porting myself.
> 
> absolutely necessary given the prospect of adding new backends is the
> removal of the separator argument from the read/writeEntry methods that
> deal with lists.
> given the somewhat sicko mix of xdg lists and kde lists in some of our
> .desktop files, the two methods read/writeXdgListEntry will be added.
> it's clear that those functions will simply refuse to work with other
> backends.
> 
> on top of that, i'll deprecate entryMap and state that i might return
> broken results in the future. as time permits, i'll port the users.
> 
> unless massively objected to, i'd do the trivial renamings that met no
> specific criticism. the affected functions are generally very little
> used, so this doesn't pose porting problems.
> 
> given that i need to break BC anyway, i'd kill all the virtuals from
> kconfigbase - this is a private hierarchy, so the virtuals can be in the
> private class. the public methods would only call the private virtuals.
> makes sense?
>