Use of const arg in KConfigGroup constructors doesn't work with language bindings
Richard Dale
rdale at foton.es
Thu Mar 6 21:16:47 GMT 2008
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
More information about the kde-core-devel
mailing list