Configuration Library

[Vinay Khaitan]

Have a look at this bug report
http://bugs.kde.org/show_bug.cgi?id=106096

and read Aaron's comments there.(this mail has nothing to do with that bug 
though)
"the current clock, for instance, is not only a huge beast in terms of 
resources and performance, but it is also pretty much completely 
unmaintainable because every whim of a feature that anyone could think of was 
added. code path upon code path until it's a mess." 

I have realized it many times, as the user configuration options rises, code 
start being cluttered with many ifs and buts. Not implementing any feature is 
not the way to reduce clutter(except useless features like this bug one 
IMHO). I was thinking about how to tackle this trouble.

I am giving a method, and please comment, if it is feasible or not.

What I want is to hide the configuration option handling in code and have the 
code-flow just like it happens in real scenario in general case.

We can have a very simple library which will have at least two function
registerOption(QObject* instance, QString key, void* function) and 
callOption(QString key)

in the class, when we first access configuration file, we will register 
options to the library with a key and the function to call. the functions 
registered would be called when we call callOption(key).

Now whenver we code for any program, we have to take care of configurations. 
and the configuration option changes the path, which code takes.
a lame example(kwin):-

kwin starts-> look kwinrc->find out decoration->loads the decoration 
library->load decoration->does decoration specific handlings->finally shows 
itself to user

(the above example may be even wrong, because I dont know about kwin 
code-flow)

the above flow can be reduced to 

kwin starts->look kwinrc and registerOptions->load the decoration->shows 
itself to user
this is what is expected when there is no configuration options specified.


"find out decoration->loads the decoration library->does decoration specific 
handlings" is reduced to "load decoration' . "load decoration" is actually 
call to callOption() with correct key .
A real world code example could have been better to show its benefits, but 
still, I can think of 2 benefits of this method.

1. reduction of duplication of code.
  we get many times the situation like
  if(show==true)
        showTheObject();
 else 
       hideThe object();
 now this if-else would be reduced to one functions call purely. we can make 
that functions call even inline to make things efficient.

2. This is the benefit for which I would like this method.
  When we read main code flow, we dont want to look into 
configuration-handling. and if that is there, it clutters the code. the 
function handling is separated from main code-flow for most of the options.

One question is to why not to directly call the functions instead of using 
library. I can think of a few reasons.

1. This looks cleaner to me.
2.  You dont have to keep track of which functions to call for what option 
handling?
3. some issues with this method can be handled by separate library, like if we 
require function 1->2 to be called and then 1->3 to be called. class can 
parse key to know what sequence is needed for functions to be called.

I know that there can be many issues in this method. But I think, it is useful 
in most of the cases.
I think, I would experiment with this method in the part in which I am 
working. But experts comments will help in advance :)
If the mesthod looks feasible, we can introduce such class in kdelibs.


Thanks

Vinay Khaitan