KConfigSkeleton::usrWriteConfig()

[Cornelius Schumacher]

On Sunday 22 April 2007 14:02, Andreas Pakulat wrote:
> On 22.04.07 13:35:27, Cornelius Schumacher wrote:
>
> > In my opinion replacing the logic and extending it are two different
> > things. If both is required we should have different hooks.
>
> Why, if you can do the same in just one function.

Having detailed control about how the config is written is something different 
than just hooking in some config options which can't be written by the 
kconfig_compiler generated code. That's a good reason to separate the 
functions.

Another good reason is that it removes the need to call the base class in all 
cases including the simple ones. This can avoid problems as the API is more 
explicit. That's always a good idea.

> Also in the write-case 
> in kdevelop we need to be sure that our extended code is run _after_ the
> default code, in the case of readConfig we need to make sure our special
> code is run _before_ the default code. The only way to provide this is
> by having the customized usrWriteConfig function dictate when the
> KConfigSkeleton implementation is called. Others may have other needs
> for the order.

For these cases we could make it possible to overload the read and writeConfig 
functions, so that the application gets full control if needed. For those 
applications which don't need there still would be the simple way to override 
the usrRead/WriteConfig functions without causing any side effects.

> > Sure, but there are several problems with that. First is that an unknown
> > number of applications is now broken which relied on the previous
> > behavior.
>
> No offense meant, but those applications have been broken since quite
> some time (the change was done 10 months ago). If nobody noticed thats
> really bad.

Yes, that's a problem. It shows that changing the libraries should be done 
with special care, especially, if it's about changing the behavior which 
can't be checked by the compiler.

> > Second this is a cause for subtle errors as it's easy to forget or not
> > know in the first place, that a reimplementation has to call the base
> > class implementation there, especially as it's not documented.
>
> Well, writeConfig()'s documentation says clearly that its implemented by
> usrWriteConfig(). I guess this could use another note as you said and it
> should probably also be mentioned in KDE4Porting.html.

Yes, if we don't change it back, we clearly have to document that the function 
of the base class has to be called. That's not natural as it's not enforced 
by the API.

> > Third, as I said above, it's mixing different needs and concepts, so
> > the API is less straightforward now.
>
> IMHO its not. I have a special need for writing configs, so I implement
> usrWriteConfig. I realize I also need the default implementation, so I
> call that at a given time. To me this is quite natural.

The usrWriteConfig() function is a flavor of the Template Method design 
pattern, where the base class functions usually aren't called. So I wouldn't 
say it's natural.

-- 
Cornelius Schumacher <schumacher at kde.org>