Translation in Qt5

[Chusslove Illich]

> [: Chusslove Ilich :]
> [...] I no longer remember why I thought implicit conversion is dangerous;
> and why people didn't throw at me "don't be stupid, add implicit
> conversion". I'll have to do some digging...

Here is the argument (September 2005), cut to measure:

---------- start ----------

[Among the initial options I gave:]

Second [approach] is to [...] provide some facilities for implicit
conversion [from KLocalizedString] to QString, and some more overriding
methods to QString's original ones. This is in order to preserve as much as
possible of source compatibility and current programming habits. Positive
here is that there is no dependency on QString, and negative is that
implicit conversions are double-edged sword, selection of overriding methods
is dubious [...]

[Some people responded favoring this approach, so I said:]

[...] I did run some checks. In summary, for basic KDE modules, I got some
500+ conversion errors. Most of them (about 75%) were when the needed
argument was a KGuiItem, which has implicit conversion to QString through
one of the constructors. Most of the rest were because of QVariant, which
also has a constructor from QString.

So, one thing I tried, just to see what will happen, is to duplicate
KGuiItem's constructors to take [KLocalizedString]. But then, there were
many errors where the functions were overloaded to take both KGuiItem and
QString, so compiler now refused to pick the conversion. And I couldn't do
this for QVariant, as it is not "ours". Perhaps I could put implicit
conversion to QVariant in [KLocalizedString], but...

[Snippet of Frerich Raabe's response to the above:]

KGuiItem specifically takes strings which are visible in the GUI, maybe the
constructor which takes QString should be removed altogether and use a
[KLocalizedString] instead (which kinda emphasizes the 'Like a QString, but
for user-visible strings in KDE applications' thing about
[KLocalizedString] - maybe this should be called KGUIString or so?) - that
would solve the ambiguity you were seeing. FWIW, KGuiItem should get
explicit constructors anyway (that's been in kdelibs/TODO for quite some
time now, too).

Okay [QVariant issues] should probably looked at on a case-by-case basis.

[KGuiItem did get explicit constructors some time afterwards, but I also
made a more general complaint:]

[To have problems looked at on a case-by-case basis] is exactly what I want
to avoid. With implicit conversions, you never know what is going to happen
in the future (which is one of main reasons why they are frowned upon, that
is, as far as I have seen in the books [...]

[Michael Olbrich's response:]

No implicit conversion. That just asks for trouble. You don't know whether
the QString stored in the QVariant is before or after the arguments are
passed. If its before you would loose [KLocalizedString]'s functionality
without any warning.

---------- end ----------

And that was the end of talk about implicit conversion. toString() method
came into picture, and being burdensome to use it all the time, also the
single function call syntax by templates. (Which, as I said, came to like
regardless, but I wouldn't have pushed it if we had agreed on implicit
conversion.)

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110703/028ec897/attachment.sig>