New i18n interface for KDE 4

[Nicolas Goutte]

On Thursday 08 September 2005 17:02, Chusslove Illich wrote:
(...)
> >> [: Chusslove Illich :]
> >> First is that KI18n is inherited from QString, and only has the smart
> >> arg() methods which override QString's.
> >
> > [: Frerich Raabe :]
> > This sounds totally very wrong to me.
>
> I am certainly not a daily practitioner of C++, but I would like some more
> reasons for this. If for nothing else, to really purge it out of my head.

Well, in the discussion in kde-i18n-doc we had a few:
- QString's destructor is not virtual. 
- Without inheritance, you can create compiler errors when a KI18n is 
transformed to a locale encoding or worse to Latin1.

Also  I had pointed out that i18n() parameters are of the kind const char* and 
only the output is QString, while the intern processing is more done as const 
char* too.

I had also pointed out that internally KI18n could perhaps more need 
QByteArray, depending on the script language used.

>
> Nicolas mentions the non-dependability on QString due to possible changes
> in next major Qt, which is nice, but I said I think that many other things
> would have to be fixed throughout Qt-using code if QString changes, so
> that KI18n would be just a drop in a sea. Or is it not so?

Not necessarily.

QBuffer and QByteArray alone did not break during Qt 3.x. But if you have used 
both in a certain way, like KWord's RTF import filter did it, then you add to 
re-write the code for Qt 3.2 and again for Qt 3.3.

It is from this experience that I do not want that KI18n is inherited from 
QString.

(...)

Have a nice day!