Changes into KConfigSkeleton between kde3.x and kde4.0

[Cornelius Schumacher]

On Wednesday 16 May 2007 23:35, Laurent Montel wrote:
> On Wednesday 16 May 2007 23:03:45 Andreas Pakulat wrote:
> >
> > Instead you can just call the default implementation before or after you
> > did your own stuff, so I don't see a problem.
>
> I see a big problem, API was not changed (same function) but it doesn't
> work as previously so it's not good for guy which port application => it
> will create porting bug.
>
> why not revert as previously and use directly usrWriteConfig() when a guy
> when to customize it. (If guy want to customize it it will re-define this
> virtual function no ? )

I agree with Laurent. The behavioral change is a problem. The requirement to 
call the base class implementation is a constant source of potential and real 
bugs.

For the cases where complete control over the way of writing and reading 
configuration is needed we could make the read/writeConfig virtual. But for 
the general case I think it would be better to keep the usrWrite/ReadConfig 
as simple incarnation of the template method design pattern. (With the 
changed behavior the name of the function also wouldn't fit anymore).

-- 
Cornelius Schumacher <schumacher at kde.org>