[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-08-10 3:24:17
Message-ID: 200508100524.22410.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Nicolas Goutte :]
> So perhaps the i18n() and similar function should remain independant
> functions, however that call similar static member functions of a
> support class.
>
> I18nClass i18n( const char* cstr )
> {
>   return I18nClass::i18n( cstr );
> }

This I find to be a clear advantage. Aside from covering the problems you 
pointed out, it also prevents implicit i18n calls (which were possible 
with previous solution, and which I found out during compilation with this 
new setup :) I named the class KI18n. In compilation of kdelibs and 
kdebase, I had to make just one or two additional explicit castings to 
QString.

There is just one thingy. I actually set all constructors (except of copy) 
of KI18n to private and i18n functions as friends of KI18n, so that they 
can do:

KI18n i18n( const char* cstr )
{
  return KI18n( cstr );
}

I wanted to avoid one extra copy-construction (this should construct in 
place, while the one with static function would have one 
copy-construction; or I missed on something?) Is there a problem with this 
approach?

> As for deriving the class from QString, as written above, I do not think
> that it is a good solution. We do not control QString, but if we derive
> from it, we cannot throw away the class if it would start to annoy us
> (or for example if Apple would want to use the class in its KHTML.)

I don't quite understand this. We cannot throw away the class anyway, as 
that would break our binary compatibility. Likewise for QString, they also 
cannot break the interface for the same reason. Or am I being naive? :)

There is one other thing that is bugging me though: QString doesn't have 
virutal destructor, and I have literature-induced bad feeling about this. 
I have also declared operators new and delete to be private, in order for 
someone not to try deallocating KI18n through pointer to QString...

> So perhaps the class should not derive from anything but offer an
> operator QString to convert to a QString.

I have nevertheless tried compiling kdelibs and kdebase in this way. I 
don't know how representative this sample is, but it took about 210 
changes (explicit casts) in 100 files to make them compile to the end. 
But, the structure of the changes is curious.

125 changes were needed because KGuiItem has a constructor that takes a 
QString, and it was called by passing result of i18n to it. So there would 
have to be conversion KI18n->QString->KGuiItem, which is against standard. 
And there is a comment attached to the troublesome constructor of 
KGuiItem, saying that this implicit conversion from QString should perhaps 
be dropped in KDE4.

Most of the rest of explicit casts (75) were needed due to invoking methods 
local8Bit() and length() directly on result of i18n call. The remaining 
few casts (<10) were with few other methods of QString, some == and 
ternary ops and assignments.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]