From kde-core-devel  Thu Mar 06 21:16:47 2008
From: Richard Dale <rdale () foton ! es>
Date: Thu, 06 Mar 2008 21:16:47 +0000
To: kde-core-devel
Subject: Re: Use of const arg in KConfigGroup constructors doesn't work with
Message-Id: <200803062116.47681.rdale () foton ! es>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=120483853900787

On Thursday 06 March 2008 07:58:28 Stephan Kulow wrote:
> Am Mittwoch, 5. März 2008 schrieb Richard Dale:
> >     /**
> >      * This variant of the constructor is useful for non-c++ languages
> >      * without const argument overloading.
> >      *
> >      * ### KDE 5 make isConst default to true
> >      */
> >     KConfigGroup(KConfigBase *master, const QString &group, bool
> > isConst); KConfigGroup(KConfigBase *master, const char *group, bool
> > isConst);
> >
> > Is it ok to commit this to the trunk?
>
> Hi Richard,
>
> I understand your problem, but this basically defeats all purpose of
> cleaning up our C++ API ;(
So is the KDE 4.x about creating a great C++ api, or is it about creating an 
api that looks as clean as possible in commonly used languages?

> Is there really no better way than adding a "weired" constructor with a
> bool?
But non const/const is boolean, and all I've done is make the C++ semantics of 
the const/non-const KConfigGroup constructors explicit for non-C++ languages. 
If you find that ugly, then you might understand better why non-C++ 
programmers find C++ ugly. Also the api is conflating runtime semantics with 
compile time issues. What if I create a KConfigGroup from a non-const master 
(parent) but define the result as 'const KConfigGroup', which is const and 
then construct another KConfigGroup. Should the end result go on the compile 
time const-ness, or by inheriting the runtime flag bConst?


> Like maybe a KConstConfigGroup class that is only overwriting the
> constructors?
I don't like that one as it seems weirder than adding a couple of constructors 
to the KConfigGroup class.

-- Richard