vkhaitan at gmail.com
Wed Nov 2 09:44:31 GMT 2005
Have a look at this bug report
and read Aaron's comments there.(this mail has nothing to do with that bug
"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
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
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
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
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.
More information about the kde-core-devel