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

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-08-10 17:02:54
Message-ID: 200508101902.54094.nicolasg () snafu ! de
[Download RAW message or body]

On Wednesday 10 August 2005 05:24, Chusslove Illich wrote:
> > [: 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?

I suppose that using "friend" is good here. (I had bothered David Faure enough 
with telling him not to use static functions to create objects but to use 
constructors instead, so may be I could tell the same thing to my previous 
idea.)

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

First I thought more that your idea should be done in a way that can be 
re-used by non-Qt software. By not implemeting the class as derived from a 
particular string class, this will be easier, for example because it is clear 
when you read or write the string object.

Good, perhaps my argument was not the best.

However if the class has its own private class d, like any good public KDE 
class, you do not care if d constains (in Qt4 classes) QString, Q3CString, 
QByteArray or std::string . And you do not have to change your binary 
compatibility.

Also books about OO programming tell to derive one class from another if there 
are of a same kind. That is not eaxctly the case here, as QString is a class 
for holding a string and KI18N is for processing translations. (Also you 
handle strings with const char* too.)

As for not breaking the interface, well Qt 3.x broke the behaviour between 
QBuffer and QByteArray two times. That is another reason why I think that 
classes should be clearly eeparated.

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

See, because you have derived one class from another, you are starting to 
"peek and poke" around. That are clear signs that the derivation is bad.

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

Good, perhaps. You must see if the change are more in a way to make the code 
better or if it is in the direction of making more hacks.

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

But then we can add a constructor with KI18N as parameter. Or add an operator 
that returns KGuiItem.

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

However if there is a code change here, it should be looked why and in which 
direction.

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

You can have there funtions as members of KI18N. That is not the problem. But 
compared of directly deriving from QString, you are controlling the 
interface.

Have a nice day!

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