New i18n interface for KDE 4

[Chusslove Illich]

> [: Nicolas Goutte :]
> There is a (big) difference about creating clear member functions and
> about tweaking with vital functions of a class in a way that is not
> guaranteed to be supported by all C++ compilers.
>
> (But I will not be the one who will maintain it. I just want to avoid
> you a potential nightmare. But as my father often used to say:
> "Experience cannot be transmitted.")

I don't see much of a maintenance problem just because of overloaded 
operator new. It is a standard language feature, and configure time check 
can find out if compiler is broken. If it is, then on that platform 
operator new simply will not be overloaded.

GCC 3 and 4 can overload new, I expect that modern Windows compilers can 
also do it, so the systems with broken compilers on which KDE can be 
compiled, will be minor. The probability of someone developing KDE code on 
such a system *and* dynamically allocating KI18n is very, very small. And 
if it happens, such code will not compile on majority of platforms.

However, I do think there is much truth in your father's saying :)

> To get a point that we already had on the kde-i18n-doc mailing list:
> both classes are not made to be the same. QString is about handling
> strings, KI18n is about handling translations. (So in a classical
> object-oriented programming style, they should not inherit.)

Again, I don't mind that view of things, but the alternatives we've came up 
so far seem to me all having worse problems (and not possibly in the 
future, but right now). Also, normally when you think about design, you 
think about changing the way people do some things. In the case of 
inherited KI18n, this is not at all so, as we expect usage patterns to 
remain almost exactly the same as they already are (i.e. high preservation 
of source compatibility).

So what do we do? We could fall to that "If you can't do it right, don't do 
it at all". But that would be excessive in this case, as the very features 
that you are afraid might break KI18n (QString's implementation) are the 
ones which would break current i18n interface as well.

-- 
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/20050911/7a7010b1/attachment.sig>