Changes into KConfigSkeleton between kde3.x and kde4.0

Andreas Pakulat apaku at gmx.de
Thu May 17 00:09:03 BST 2007


On 17.05.07 00:38:08, Cornelius Schumacher wrote:
> 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.

Well, Adam just forgot to add the porting notes - IMHO. And the
requirement to call a base class impl. if you want the default behaviour
is IMHO pretty normal in OO world. 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).

> 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.

Well, I think usr* is just redundant if the normal methods are virtual,
but whatever you guys decide (you know I'm not really a kdelibs hacker
;) is fine with me as long as I can have complete control over the
implementation of those function.

Andreas

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)

-- 
You can do very well in speculation where land or anything to do with dirt
is concerned.




More information about the kde-core-devel mailing list