[RFC] KConfig API stuff

Andreas Hartmetz ahartmetz at gmail.com
Tue Oct 23 16:26:46 BST 2007


Am Dienstag, 23. Oktober 2007 16:08:09 schrieb Oswald Buddenhagen:
> On Tue, Oct 23, 2007 at 03:24:56PM +0200, David Faure wrote:
> > > no, otherwise the old name rollback() would fit. ;)
> >
> > I never had a problem with the old name :-)
>
> well, no, because you didn't understand what it does. :-P
>
> > > it sort of fits reverting the add of a new file - afterwards the file
> > > is still there, but not known to svn any more. however, i never would
> > > see this parallel if not pointed to.
> >
> > It sounds like I don't understand what this method does then.
>
> indeed. :-(
>
> > Isn't about
> >  group.writeEntry(...);
> >  group.writeEntry(...);
> >  group.writeEntry(...);
> >  group.writeEntry(...);
> >  // oh wait this was no good, revert
> >  config.revert()
> > ?
>
> as i tried to point out two times already (after being enlightened by
> thomas), this is *not* what this function does.
>
> as summarized in the other mail by maelcum, the use cases can be reduced
> to:
> - markAsClean() + reparseConfiguration(), i.e. an actual
>   rollback/revert/reset/call-me-what-you-will
> - markAsClean() + destruct (usually called in the parent object's d'tor)
>
That wasn't me, or was it? :)

> the latter is sort of just an optimized version of the former - if one
> wanted to, one could have only a rollback() with lazy reload semantics -
> dunno if i could conjure it up as fast as needed.

This is *not* a poem writing contest. Have you ever played this game
http://en.wikipedia.org/wiki/Taboo_(game) ?
You win by finding the least ambiguous description fastest, everything else 
doesn't matter.
undirty() is perfectly clear if you have ever heard of a dirty cache.
For someone who doesn't know the terminology a long name is probably 
unavoidable. And it won't really hurt either because it's rarely used... Huh, 
I wonder why the functionality is needed at all.

I am not saying anything for or against changing this at all.




More information about the kde-core-devel mailing list