Configuration Library

[Vinay Khaitan]

My idea was a rudimentry one, and it has to be not just refined but also 
extended, I already know. My only purpose was to find out the trouble with 
the idea.
For tackling the configuration trouble, I had two mre ideas.
One was utilizing macro, which i immediately abandoned because of being 
non-flexible.
The other one was quite good, But I didn't think much about it.
that is moc/kconfig_compiler like parser of code. It will have much greater 
flexibility, but for the time being, I forget it.

> On Wednesday 02 November 2005 10:44, Vinay Khaitan wrote:
> > registerOption(QObject* instance, QString key, void* function)
>
> Non-type-safe function pointers are really not appealing to me.
Definitely I second it. actually void* was just first thing came into my mind 
in a millsecond :)
Cant we make registerOption aware of type of function?
instead of void* we can have QVariant* ? then registerOption() function would 
find out the correct type and make that function type-safe?
If QVariant comes out to be overhead or non-safe(because of automatic 
casting), we can make similar lightweight class with type safety and new 
classes can be registered like QMetaType?

> Anyhow the idea seems broken to me. No support for options that depend
> on each other, so for every option callback being activated we'd set up
> everything in a way, and then another callback is called and we set up
> things differently; and relayout/update everything - where we could have
> done the right thing in the first place.
> If the amount of options remains, the complexity remains, the code just has
> to be written "correctly" to handle those cases, unless the number of
> options is reduced.
This problem surfaced when I was talking with a other dev.
I had the idea of key parsing by library for the purpose of calling correct 
function sequence or correct function. We can have the key passed like "key1? 
key2: key3", for the purpose of multiple option dependent call ?
I dont like this idea, because, it still doesn't hide configuration thingie 
from main code flow.
What I envision is that, actually multiple option dependent call are construct 
of programming logic, instead of real world need.
see this example:-
we have two boolean option 
"keep hidden" 
"auto-hide"
in certain situation, 
object would be shown when (!("keep hidden" && "auto-hide"))
and in a different situation it would be (! "keep hidden" )

for this purpose, we will have only one function registered "void show(key)"
this function would see which situation is relevant at present. This will 
totally hide the configuration things from main code.
What is important to node here is that, our real world need is only one, to 
show the object. so that is what is registered.
May be the situation cant be seen only from the main code, because not all 
parameter is present in other code.
in that case, the function can be made of variable argument list, just like 
printf() .
One more solution, which comes to my mind is that , we can have somehow 
specified the interdependence of options to library, so that it can tackle 
the situation of calling a function or not calling?

The only thing to say on this is that the possibility or arraging code to look 
more readable and cleaner is surely there. We must investigate it.

Vinay Khaitan