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

List:       kde-core-devel
Subject:    Re: KDE:: namespace [Re: KCModule::init()]
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-10-10 19:52:04
[Download RAW message or body]

On Wed, Oct 10, 2001 at 12:30:10PM -0700, Kurt Granroth wrote:
> On Sunday 07 October 2001 18:20, Carsten Pfeiffer wrote:
> > What about using a KDE namespace for kdelibs classes?
> 
> I think the idea of moving KDE libs to use the KDE namespace is a great
> idea.  Is there any good reason for NOT doing this?

It breaks source compatibility on a larger scale. typedef's like
typedef KDE::KAboutData KAboutData are unfortunately not enough to
keep compatibility. The other part are signals/slots, the arguments
of them in particular.

Example:

namespace KDE
{
    class Foo
    { ... }

    class Blah : public QObject
    {
        Q_OBJECT
    public:
        ....
    signals:
        void somethingChanged( Foo *);
    }
};

Ok, so far. Now let's define a slot for that signal:

class Blop : public QObject
{
...
private slots:
    void setBliep( Foo * );

Oh wait, that doesn't compile, Foo is in KDE namespace. So you have
to write instead:

private slots:
    void setBliep( KDE::Foo *);

And _that_ in turn requires you to break source compatibility in
your kdelibs class Blah, because you now have to change your signal
signature to

signals:
    void somethingChanged( KDE::Foo * );

I do not think we should change all signals in kdelibs matching this
problem, just for a KDE namespace. Yes, the above can be avoided if
instead people write 'using namespace KDE;' everwhere, but then we
are exactly where we are now. In addition I don't like to write
KDE::URL instead of KURL. More to type without really gaining
something, IMHO.

I think the idea of namespaces is to solve clashes in class names
for large scale projects. I don't think we have run into such
clashes that often, yet (in fact I can't think of any right now ;-)

/me thinks K is smart enough, like Q ;-)

Simon

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