[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: New i18n interface for KDE 4
From: Nicolas Goutte <nicolasg () snafu ! de>
Date: 2005-09-11 0:29:21
Message-ID: 200509110222.44674.nicolasg () snafu ! de
[Download RAW message or body]
On Saturday 10 September 2005 19:28, Chusslove Illich wrote:
> > [: Nicolas Goutte :]
> > 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.)
>
> It doesn't seem to me more of a hack than placing implicit conversions
> around, on a per-case basis. Thinking practically, I don't see a problem
> with this hack, while with implicit conversions I do (and already have
> them).
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.")
>
> > [...] 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.
>
> That is my basic idea of KI18n: a language-aware QString, which will
> translate itself when appropriate.
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.)
>
(...)
Have a nice day!
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic