RFC KAutoConfig

[Benjamin Meyer]

On Friday 14 February 2003 3:30 am, Cornelius Schumacher wrote:
> On Thursday 13 February 2003 17:03, Benjamin Meyer wrote:
> >  *
> >  * The name of the widget determines the name of the setting.  The
> > initial * value of the widget also is the default when asked to reset.
> >  *
> >  * This class was created to further follow the DRY principle.
> >  * DRY - Don't Repeat Yourself
>
> One main problem with config settings is that you have to repeatedly write
> the name of the setting (which is used as key in KConfig) as string, e.g.
> at the place in the application where the setting is read and at another
> place where it is written (in case of KAutoConfig this would be in the ui
> file, right?).
>
> This is a problem because the compiler isn't able to do any checks on them,
> so typos can be very hard to find.
>
> Does you class address this problem in any way?

I don't see why it should or even could be solved.  There is no way to check 
for the error that you are describing.  The developer is actually more likely 
to spell a setting wrong the old way sense they would have to type the 
settings text 3 time (save/reset/restore not including the object name) while 
with kautoconfig you would only have to write it once when declaring the 
object (either in designer or hand coded).  As a developer retrieving the 
wrong setting due to a spelling error is just a small annoyance that everyone 
has had at one time.

> >  * The only major downside to this class is that it is almost guaranteed
> > (?) * to be slower then the normal implimentaions.  Thus the design of
> > the class * is geared towards improving the speed of its operation.
>
> How much slower is KAutoConfig than the traditional way?

Hardly noticeable.  In fact the more that I think about it the more that I 
think the trade off is a good thing.  The cost due to the abstraction is 
gained back ten fold from the knowledge that time wont have to be wasted 
coding the same thing yet again, fixing the silly bugs that would occur doing 
that, and the ability to very easily add new features like immutable on a 
global scale.  Because abstraction is always more costly then straight access 
the class was designed to complete its jobs as quickly as possible.

I have gotten a lot of positive feedback (including tips which I have 
incorporated) and if there are no objections I would like to move it into 
kdecore.  I have taken several steps neccesary including abstracting out the 
private data in a private class and adding comments to the functions (and 
even spell checking them!) for kdoc.

-Benjamin Meyer