New i18n interface for KDE 4

[Chusslove Illich]

> [: 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.

> - 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.

(*) 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.

> 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.

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

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

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...

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050908/e0c95c53/attachment.sig>