New i18n interface for KDE 4

[Nicolas Goutte]

On Thursday 08 September 2005 20:32, Chusslove Illich wrote:
> > [: Nicolas Goutte :]
> > Well, in the discussion in kde-i18n-doc we had a few:
> > - QString's destructor is not virtual.
>
> For this reason a have made operators new and new[] private, so that we
> don't come into a situation that someone tries to delete KI18n through
> QString pointer.

But that is a hack. (I am not even sure that you can overload new, at least in 
old C++ compilers you could not, not sure about modern C++ compilers.)

>
> > - Without inheritance, you can create compiler errors when a KI18n is
> > transformed to a locale encoding or worse to Latin1.
>
> I don't think this is much of a guard, as someone who doesn't know what he
> is doing (*) is likely to first dig up the fact that there is conversion
> to QString operator, and do it anyway.

Yes, but we can document in KI18n's Doxygen documentation, what should not be 
done. Otherwsie, developers will think that it is just a Qstring derivate and 
use it like a QString.

>
> (*) While testing, I found 18 local8bit() and 5 latin1() calls directly on
> results of i18n(). Perhaps we should check those out, but I really hope
> they are mostly not blunders.

The ones of Kexi are already reported. As for the others, I do not know.

>
> > 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 do use a QString inside, one way or the other. That is because the
> ordinary translation must be maintained, so it is easiest to just call
> QString::arg() method to fill that internal QString. I also use
> QString::arg() as a mean of collecting arguments, to be passed to
> scripting engine as array of strings.

Yes, but what I mean is that is the point of view of today. If you change your 
point of view before KDE5, you cannot change it once KDE4 is out, if KI18n is 
derived from QString.

>
> > I had also pointed out that internally KI18n could perhaps more need
> > QByteArray, depending on the script language used.
>
> With Guile it is true that I need UTF8 byte sequence in the end, but as I
> said above, I anyway use a lot of QString. And this kjs, perhaps it will
> consume QStrings?

As far as I know, kjs has its own string class, but I really do not know the 
implementation.

>
> > 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.
>
> Is this perhaps because some undocumented behavior was used?

No, the behaviour was documented but buggy. Trolltech had to correct as good 
as possible, however for the filter it was not good enough.

>
> On the underlying QString I use only its arg() methods, copy constructor
> and operator=. If these are reimplemented between minor versions of Qt
> such that their behavior becomes different, again, a lot more code will
> break. Or, from this point of view, we are no more safe using QString as
> internal member, to guard we would have to not use QString at all...

Again it is less the class by itself. It is that Trolltech has a conception of 
QString, which might not be the one of KDE and might even less be the one 
needed for a class derived from QString.

As for binary/soruce compatibility of Qt, I would not consider it 100%. (Qt 
3,2 broke many things with its implicit shared classes.)

Have a nice day!