From kde-core-devel Wed Jul 25 18:11:48 2001 From: Charles Samuels Date: Wed, 25 Jul 2001 18:11:48 +0000 To: kde-core-devel Subject: Re: RFC: KConfig changes for 3.0 X-MARC-Message: https://marc.info/?l=kde-core-devel&m=99608491121633 On Wednesday 25 July 2001 11:08 am, Martijn Klingens wrote: > On Wednesday 25 July 2001 19:28, David Faure wrote: > > On Wed, Jul 25, 2001 at 07:40:18AM -0700, Charles Samuels wrote: > > > In addition to Rob's comments, we should eliminate the obvious lack of > > > OO safety in KConfig and always explicitly set a group when accessing a > > > key. > > > > > > My personal favorite way is a group(QString) function that returns a > > > temporary KConfigGroup. > > > > > > In other words > > > > > > config->group("Some Group Name")->readEntry("Some Key"); > > > > This is an excellent, excellent idea. > > And with a KConfigGroup * you could cache the value of > > config->group("Some Group Name") in case you're reading multiple keys > > from it. > > And it's not hard to keep source compat, with the readEntry and setGroup > > still available in KConfigBase. > > And it's not hard to implement either :) > > > > Yes yes yes, this gets a 100000% vote from me :) > > I fully agree here too, but one question about the syntax: is operator > overloading a better way here? Like > > - config->group("Some Group Name")->readEntry("Some Key"); > + config[ "Some Group Name" ][ "Some Key" ]; Actually, that would be: (*(*config)["Some Group Name])["Some Key"]; And frequently, you need the default value for readEntry, which can't be done with the operator[] Unless you want a KConfigEntryMoniker object with a operator QString() member. (Am I going too far?) I think you can see where the problem with that is :) If we add dummy classes that wrap around the pointer, it solves that, but still... bloaty. There's also problems with KConfig inheritence (non virtual methods for example). If we could find a clean way to do this, without the bloatyness of the wrappers, then I'm ok with it. -Charles