Use of const arg in KConfigGroup constructors doesn't work with language bindings

[Richard Dale]

On Wednesday 05 March 2008 09:02:29 Thiago Macieira wrote:
> On Wednesday 05 March 2008 09:02:49 Lubos Lunak wrote:
> >  No. In fact it is less clear and more error prone. Using 'const' is a
> > normal C++ way and it lets the language to handle constness
> > automatically. The code you posted will not work (compile) if the
> > KConfigBase is already const and it forces the developer to do manually
> > what the compiler can do on its own (and the compiler is not human, so
> > unlike the developer it should not do mistakes :) ). It is rather common
> > to overload methods in C++ based on constness and I'm surprised this is
> > the first time you've run into it.
>
> I'd say that we should have both things:
>
>  KConfigGroup(KConfigBase *master, const QString &group, AccessType mode =
> ReadOnly);
>  KConfigGroup(const KConfigBase *master, const QString &group);
>
> i.e., the second form is enforced read-only, whereas the first can be
> selected. For instance, I could have a read-write KConfigBase * that I
> wanted to create a read-only form from. Casting it into const seems bizarre
> to me.
>
> In order to maintain binary compatibility, we can't have the first form,
> but we have to introduce a third with a non-default argument. And add a ###
> KDE 5 marker.
The attached patch add two extra constructors with a bool 'isConst' argument:

    /**
     * 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?

-- Richard



-------------- next part --------------
A non-text attachment was scrubbed...
Name: kconfiggroup_constructor.patch
Type: text/x-diff
Size: 1782 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080305/6410e729/attachment.patch>