[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:       Charles Samuels <charles () kde ! org>
Date:       2001-07-25 18:11:48
[Download RAW message or body]

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

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