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

[Lubos Lunak]

On Wednesday 05 of March 2008, Richard Dale wrote:
> Well are we designing the KDE api to be relatively language independent?

 I guess that depends on what you mean with relatively. I don't think we 
should intentionally break other languages, but then I don't think we should 
intentionally break our libraries because of other languages either. To take 
it to an extreme, since automatic invocation of destructors doesn't work with 
any other language than C++, should we stop using that?

> If so there is no reason why we can't have extra method calls to cater for
> the languages without const overloading. The KConfig constructor takes a
> OpenFlags enum, and the KConfigBase takes an AccessType enum - so why isn't
> KConfigGroup consist with them. In fact what is the difference between the
> AccessType value in KConfigBase and bConst in KConfigGroup?

 That's what Thiago suggests and that's different from what you wanted 
originally. Thiago's proposal is fine, removing const is breaking it.

> I don't think it's the first time I come across it in KDE, but I'm pretty
> sure that the Qt lib doesn't do it anywhere (anyone know of any examples?).

 Any operator[], at least. But that probably doesn't map to other languages 
either.

> The method above is a constructor and 'master' is something like the parent
> of a QObject. When you construct a QObject I wouldn't expect it to be
> read-only or not according to whether the parent arg was const or not.
> Similarly the connection between whether or not master is const, and
> whether or not it follows that the child KConfigGroup is read-only is
> something that you would need implementation knowledge to know if it makes
> sense.
>
> In the KConfigGroup a boolean bConst, is set in the constructor, and that
> is used afterwards to test whether the instance is read-only or not. It
> doesn't matter if you declare it 'const KConfigGroup * item' or
> 'KConfigGroup * item' - there is no use made of compile time checking.

 You're mixing two things here. If KConfigGroup takes a const KConfigBase, 
then that KConfigBase is not to be modified, simple as that. And it works two 
ways, KConfigGroup taking const argument says that it won't be modified, and 
somebody passing const KConfigBase says that it is not to be modified. The 
compiler will do special handling to detect and enforce that and the fact 
that KConfigGroup has a special flag for that is just an implementation 
detail. KConfigGroup being read-only when it gets a const KConfigBase is just 
a logical consequence of it not being possible to be read-write when the data 
it operates on is const. I don't think anybody would expect QFile to be 
read-only or read-write depending on whether the QString with the filename is 
const or not.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz