KDE 4 namespaces

[Thiago Macieira]

Richard Smith wrote:
>If we do go the route of namespaces (which I think would be a good
> thing), I'd like to suggest we call our top-level namespace KDE40, and
> put
>
>namespace KDE4 = KDE40;
>namespace KDE = KDE4;

Even though that's possible, that raises the question: do all compilers we 
support, support that?

>in some suitable header file. This means that processes will be able to
> have KDE4 and KDE5 (!) libraries in the same address space (which is
> not as crazy as it sounds, I promise). Plus, when KDE4.1 comes along,
> it means we can do funky things like this:
>
>namespace KDE40
>{
>	class MyClass {/*...*/};
>}
>
>namespace KDE41
>{
>	using namespace KDE40;
>	class MyClass {/*source-compatible, but not BC*/};
>}
>
>namespace KDE4 = KDE41;
>
>and get away with making some (non-BC but source-compatible) changes we
>previously couldn't. I'm not yet convinced of whether this is a
> practical idea.

Nor am I. Technically, it would be possible, but it would lead to a LOT of 
code duplication. You can't simply create a new set of versioned 
functions, like C can. You must recreate your entire class in order to 
achieve anything. And if your class is derived further, the whole 
descendency will need to be duplicated as well.

>> 2) Two-level naming
>>   We should avoid creating namespaces inside namespaces, except for
>> the top-level KDE namespace.
>
>I'd be interested in seeing justification for this. In my experience,
> people use a lot of using-directives in the presence of namespaces. At
> work, we use namespaces three or four levels deep, and it doesn't cause
> any problems (in fact, it's helpful).

I limited to 2 because, when talking to people, I found a lot of 
resistence to longer names.

If it were up to me alone, I'd take taglib as the guide: 
TagLib::Ogg::Vorbis:File (derived from TagLib::Ogg::File, derived from 
TagLib::File).

>> Namespace KDE::IPC
>> ------------------
>> Uses: KDE::Core, KDE::Network
>> This namespace contains the Inter-Process Communication classes, or
>> DCOP/DBUS/alike.
>>
>> Questions:
>> - Will KDE::Core require this? If so, must be moved up, maybe to
>>   KDE::Core::IPC (violation of rule #2), or be left as a non-KDE
>>   namespace, like DCOP.
>
>Best if KDE::Core didn't depend on KDE::IPC. Else KDE::Network depends
> on KDE::Core depends on KDE::IPC depends on KDE::Network.

Not really. libdbus and libdcop themselves are non-KDE libraries, so 
there's no problem in having the IPC inside the Core. DCOP doesn't use 
our networking classes today either (even though that leads to 
duplication).

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

4. And æfter se scieppend ingelogode, he wrát "cenn", ac eala! se 
rihtendgesamnung andswarode "cenn: ne wát hú cennan 'eall'. Ástynt."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050509/e0cd9907/attachment.sig>