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