Changes into KConfigSkeleton between kde3.x and kde4.0
apaku at gmx.de
Thu May 17 01:21:13 BST 2007
On 17.05.07 01:42:23, Cornelius Schumacher wrote:
> On Thursday 17 May 2007 01:09, Andreas Pakulat wrote:
> > In fact I find such things like
> > writeConfig+usrWriteConfig much uglier and weird than just calling the
> > base class impl. in a subclass' writeConfig (when this function is
> > virtual).
> The problem is that you create a dependency on the implementation of a certain
> method in the API. As the use case in question demonstrates a change in the
> implementation breaks the API. If you have a separate method for
> customization like useWriteConfig you don't need to know about the
> implementation of writeConfig.
Well, you don't need to know the implementation of writeConfig, you just
need to know wether you want to store the information of the items to
the config yourself or just do something not that intrusive.
> > PS: Adam's commits where 560326 and 559982, which is quite some time
> > ago, I really wonder why people start to notice just now. (yeah I know
> > porting against moving kdelibs wasn't easy until now)
> It shows that the bugs introduced by the change weren't obvious. They didn't
> break compilation, but the behavior of applications in a somewhat subtle way.
> Which definitely is a problem since people changing the libraries don't test
> running applications.
Adam surely tested that his changes worked in kdevelop ;) But I do
understand the problem. So as I said, as long as you make the
read/writeConfig and set/useDefaults methods virtual so they can be
changed completely in subclasses its fine with me reverting the changes.
Your own qualities will help prevent your advancement in the world.
More information about the kde-core-devel