New i18n interface for KDE 4

[Michael Olbrich]

On Sun, Sep 11, 2005 at 06:11:43PM +0200, Guillaume Laurent wrote:
> On Sunday 11 September 2005 18:01, Chusslove Illich wrote:
> > >> [: Chusslove Illich :]
> > >> I don't see much of a maintenance problem just because of overloaded
> > >> operator new.
> > >
> > > [: Guillaume Laurent :]
> > > You might want to look harder :-).
> > > [...]
> > > It's also one of those which got C++ it's reputation of a
> > > highly-complex-makes-it-easy-to-hang-yourself-while-shooting-yourself-
> > > in-the-foot language. I agree with Nicolas, overloading new() is not
> > > something you do casually.
> >
> > Please excuse me if I am being redundant, but I'd just like to make sure we
> > are still in the same context. It is not that I want to really provide a
> > custom new(), but rather to disable it by declaring it private. (As far as
> > I understood, Nicolas' objection was that not all compilers will allow
> > that.) This comment still holds then?
> 
> Oh then no, this doesn't imply any serious maintenance or debugging problems.

I think we can all agree that it is _possible_ to inherit Ki18n from
QString. The question should be whether it makes sense from a design
point of view. The only argument _for_ inheriting I've seen so far is
that it breaks less code. But is that really an argument? We are at the
beginning of a release cycle. Right now is the time to break things to
do it _right_.
So I think we should stop discussing what is possible and think about
the best way of doing it.

michael