[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: KConfig changes for 3.0
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-07-25 18:07:47
[Download RAW message or body]

On Wed, Jul 25, 2001 at 08:08:23PM +0200, 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" ];
> 
> It seems to me that KDE dislikes this syntax, because it is hardly used, but 
> I wonder why.

Because it would have to be (*config)["group"], and this looks really ugly.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]